You can find the inventory of the sources registered in Axoflow Console on the Sources page.
For an overview of where the different sources are sending data, see the Topology page.
To analyze your data at various points in your pipeline, see the Analytics page.

1 - Generic tips

The following section gives you a generic overview on how to configure a source to send its log data to Axoflow.

If your source has a specific entry in the Vendors section, follow that instead of the generic procedure.
To collect data from an edge host, see Edge collection rules.
- Sources are hosts that are sending data to a data aggregator, like AxoRouter.
- Edges are source hosts that are running a collector agent managed by Axoflow Console, or have an Axolet agent reporting metrics from the host.

CAUTION:

Make sure to set data forwarding on your appliances/servers as described in this guide. Different settings like alternate message formats or ports might be valid, but can result in data loss or incorrect parsing.

Default connectors

Sources can send their data to an AxoRouter connector. By default, Axoflow Console has AxoRouter connector rules that create the following connectors on AxoRouter deployments.

The following connector types are available:

Parsing and classification is enabled for the default connectors. To create other connectors, or modify the default ones see AxoRouter connector rules. (The default connector rules have “Factory default connector rule” in their description.)

Open ports

By default, AxoRouter accepts data on the following ports (unless you’ve modified the default connector rules):

514 UDP and TCP for RFC3164 (BSD-syslog) and RFC5424 (IETF-syslog) formatted traffic. AxoRouter automatically recognizes and handles both formats.
601 TCP for RFC5424 (IETF-syslog) and RFC3164 (BSD-syslog) formatted traffic. AxoRouter automatically recognizes and handles both formats.
6514 TCP for TLS-encrypted syslog traffic.

4317 TCP for OpenTelemetry log data.

To receive data on other ports or other protocols, configure other connector rules for the AxoRouter host.

For TLS-encrypted syslog connections, create a new connector rule or edit an existing one, and configure the keys and certificates needed to encrypt the connections. For details, see Syslog.

Note Make sure to enable the ports you’re using on the firewall of your host.

Prerequisites

To configure a source to send data to Axoflow, make sure that:

You have administrative access to the device or host.
The date, time, and time zone are correctly set on the source.
You have an AxoRouter deployed and configured with a Syslog connector that has parsing and classification enabled (by default, every AxoRouter has such connectors). This device is going to receive the data from the source.
You know the IP address the AxoRouter. To find it:
1. Open the Axoflow Console.
2. Select the Routers or the Topology page.
3. Select on AxoRouter instance that is going to receive the logs.
4. Check the Networks > Address field.

Steps

Log in to your device. You need administrator privileges to perform the configuration.
If needed, enable syslog forwarding on the device.
Set AxoRouter as the syslog server. Typically, you can configure the following parameters:
- Name or IP Address of the syslog server: Set the address of your AxoRouter.
- Protocol: If possible, set TCP or TLS.
  
  Note If you’re sending data over TLS, make sure to configure a TLS-enabled connector rule in Axoflow.
- Syslog Format: If possible, set RFC5424 (or equivalent), otherwise leave the default.
- Port: Set a port appropriate for the protocol and syslog format you have configured.
  
  By default, AxoRouter accepts data on the following ports (unless you’ve modified the default connector rules):
  - 514 UDP and TCP for RFC3164 (BSD-syslog) and RFC5424 (IETF-syslog) formatted traffic. AxoRouter automatically recognizes and handles both formats.
  - 601 TCP for RFC5424 (IETF-syslog) and RFC3164 (BSD-syslog) formatted traffic. AxoRouter automatically recognizes and handles both formats.
  - 6514 TCP for TLS-encrypted syslog traffic.
  - 4317 TCP for OpenTelemetry log data.
  To receive data on other ports or other protocols, configure other connector rules for the AxoRouter host.
  
  For TLS-encrypted syslog connections, create a new connector rule or edit an existing one, and configure the keys and certificates needed to encrypt the connections. For details, see Syslog.
  
  Note Make sure to enable the ports you’re using on the firewall of your host.
Add the source to Axoflow Console.
1. Open the Axoflow Console and select Topology.
2. Select Create New Item > Source.
  - If the source is actively sending data to an AxoRouter instance, select Detected, then select your source.
  - Otherwise, select the vendor and product corresponding to your source from the Predefined sources, then enter the parameters of the source, like IP address and FQDN.
  Note During log tapping, you can add hosts that are actively sending data to an AxoRouter instance by clicking Register source.
3. (Optional) Add custom labels as needed.
4. Select Create.

Note If your syslog source is running syslog-ng, Splunk Connect for Syslog (SC4S), or AxoSyslog as its log forwarder agent, consider installing Axolet on the host and instrumenting the configuration of the log forwarder to receive detailed metrics about the host and the processed data. For details, see Manage and monitor the pipeline.

2 - Edge collection rules

Collection rules define how edge hosts collect their local data. To collect data from non-edge sources, see AxoRouter connector rules.

Sources are hosts that are sending data to a data aggregator, like AxoRouter.
Edges are source hosts that are running a collector agent managed by Axoflow Console, or have an Axolet agent reporting metrics from the host.

Note Collection rules and data forwarding rules are currently supported on Windows hosts.

Collection rules are high-level policies that determine how data should be collected on a set of edge hosts based on dynamic host labels.

To see every collection rule configured in Axoflow Console, select Sources > Collection Rules from the main menu.

Collection rules list

Collection rules have the following main elements:

the way they collect data (for example, from files, or Windows Event Logs), and other specific parameters (for example, the path and filename)
the edge selector, which determines the list of edge hosts that will create an edge connector based on that rule.

You can use any labels and metadata of the edge hosts in the edge selectors, for example, the hostname, or any custom labels. For example, using the label.product = windows selector will create an edge connector only on Windows hosts.

Selecting a collection rule shows the details of the rule, including the list of Matched hosts: the edge hosts that will have an edge connector based on that rule. If you click on the name of a matched host, the Collection Rules page of the AxoRouter host opens, showing you the edge connectors configured for that host.

Create collection rule

To create a new connector rule, complete the following steps.

Select Routers > Connector Rules > Create New Rule. (Alternatively, you can select Add Connector > Create a connector rule on the Connectors page of an AxoRouter host.)
Select the type of collector you want to create. For example, File Collector. The following collector types are available:
- File Collector(OpenTelemetry)
- Windows Event Log
- Windows Event Tracing (ETW)
Configure the collection rule.
1. Enter a name for the collection rule into the Rule Name field.
2. (Optional) Add labels to the collection rule.
  
  You can use these metrics labels as:
  - Filter labels on the Analytics page
  - in the Filter By Label field during log tapping
  - in Flow Processing steps, for example, in the Query field of Select Messages steps.
3. Set the Edge Selector for the collection rule. The selector determines which edge hosts will have an edge connector based on this collection rule.
  - Only edge hosts will match the rule.
  - If you leave the Edge Selector field empty, the rule will match every edge host.
  - To select only a specific host, set the name field to the name of the host as selector.
  - If you set multiple fields in the selector, the collection rule will apply only to edge hosts that match all elements of the selector. (There in an AND relationship between the fields.) For example, label.location = us-east-1 AND label.product = windows
4. (Optional) Enter a Suffix for the collection rule. This suffix will be used in the name of the edge connector instances created on the edge hosts. For example, if the name of a matching edge host is “my-edge”, and the suffix of the rule is “otel-file-collector”, the edge connector created for the edge will be named “my-edge-otel-file-collector”.
  
  If the Suffix field is empty, the name of the collection rule is used instead.
5. (Optional) Enter a description for the rule.
Configure the options specific to the collector type. For details, see the specific pages:
- File Collector(OpenTelemetry)
- Windows Event Log
- Windows Event Tracing (ETW)
Select Create. Based on the collection rule, Axoflow automatically creates edge connectors on the edge hosts that match the Edge Selector.

CAUTION:
Make sure to configure Data Forwarding Rules for your edge hosts to transfer the collected data to an AxoRouter.

Modify collection rule

To modify an existing collection rule, complete the following steps.

Note

You cannot directly modify the edge connector of an edge host, only via modifying a collection rule.
Modifying a collection rule affects every edge host that matches the Edge Selector of the rule.
To apply an existing collection rule to a new edge host, you can:
- Add a label to the edge host so the Edge Selector of the collection rule matches the new host, and/or
- Change the Edge Selector of the collection rule to match the new host.

Find the collection rule you want to modify:
- Select Sources > Collection Rules from the main menu, then select the collection rule you want to modify.
- Alternatively, find the edge host whose collector you want to modify on the Topology page, then select Collection Rules. Find the collection rule you want to modify, then select ⋮ > Edit collection rule.
Modify the configuration of the collection rule as needed.

CAUTION:
The changes are applied immediately after you click Update. Double-check your changes to avoid losing data.
Select Update.

Add edge host to existing collection rule

To add an edge host to an existing collector rule, you have two options, depending on the Edge Selector of the collection rule:

Modify the Edge Selector field of the collection rule to include the new edge host.
Modify the labels of the edge host so it matches the edge selector of the collection rule.

2.1 - File Collector

Collect logs from a local file that’s available on the edge host.

Add new File Collector

To create a new Collection Rule that collects data from files on edge hosts, complete the following steps:

Select Sources > Collection Rules > Create New Rule. (Alternatively, you can select Add Collector > Create a collection rule on the Collectors page of an edge host.)
Select File Collector.
Configure the connector rule.
1. Enter a name for the collection rule into the Rule Name field.
2. (Optional) Add labels to the collection rule.
  
  You can use these metrics labels as:
  - Filter labels on the Analytics page
  - in the Filter By Label field during log tapping
  - in Flow Processing steps, for example, in the Query field of Select Messages steps.
3. Set the Edge Selector for the collection rule. The selector determines which edge hosts will have an edge connector based on this collection rule.
  - Only edge hosts will match the rule.
  - If you leave the Edge Selector field empty, the rule will match every edge host.
  - To select only a specific host, set the name field to the name of the host as selector.
  - If you set multiple fields in the selector, the collection rule will apply only to edge hosts that match all elements of the selector. (There in an AND relationship between the fields.) For example, label.location = us-east-1 AND label.product = windows
4. (Optional) Enter a Suffix for the collection rule. This suffix will be used in the name of the edge connector instances created on the edge hosts. For example, if the name of a matching edge host is “my-edge”, and the suffix of the rule is “otel-file-collector”, the edge connector created for the edge will be named “my-edge-otel-file-collector”.
  
  If the Suffix field is empty, the name of the collection rule is used instead.
5. (Optional) Enter a description for the rule.
Enter the path of the log file, or a pattern to match multiple files into the File pattern field, for example: C:\Windows\System32\DNS\dns.log or /path/to/**/*.log

You can use the following special characters:
- *: Matches one or more characters that aren’t path separators.
- /**/: Matches zero or more directories.
- ?: Matches a single non-path-separator character.
- [class]: Matches any single non-path-separator character from the specified class. The following classes are available:
  - [abc123]: Matches any single character of the specified characters.
  - [a-z0-9]: Matches any single alphanumeric character in the range of a-z or 0-9.
  - [^class] or [!class]: Negates the class, so it matches any single character which does not match the class.
(Optional) If needed, set advanced options under More options.
To apply a specific parser on the messages of the log file, select it from the Log format field. Currently Windows DNS and DHCP log files are supported.11
Select Create. Based on the collection rule, Axoflow automatically creates edge connectors on the edge hosts that match the Edge Selector.

CAUTION:
Make sure to configure Data Forwarding Rules for your edge hosts to transfer the collected data to an AxoRouter.

You can use these metrics labels as:

Filter labels on the Analytics page
in the Filter By Label field during log tapping
in Flow Processing steps, for example, in the Query field of Select Messages steps.

label	value
edge_connector_name	The name of the edge connector that collected the message
edge_connector_type	`otelFile`
edge_connector_label_	Labels set on the edge connector. By default: `vendor:opentelemety`, `product:otel-file`
edge_connector_rule_id	The ID of the owner ConnectorRule resource in Axoflow that created the edge connector.
edge_flow_name	The name of the edge forwarding rule that sent the message.

Advanced options

Exclude file pattern: Exclude some files that match the File pattern. You can use the same special characters as in the File pattern field.
Exclude older than: Exclude files whose modification time is older than the specified value, for example: 1h, 24h, 7d.
Multi-line start pattern: Regex pattern to identify the start of a multi-line log entry. Mutually exclusive with Multi-line end pattern.
Multi-line end pattern: Regex pattern to identify the end of a multi-line log entry. Mutually exclusive with Multi-line start pattern.
Multi-line omit pattern: If enabled, the lines matching the multiline pattern are omitted from the entry.
Force flush period: Always flush the current batch if the after the specified period. Example values: 1s, 5m, 1h. Default value: 500ms
Encoding: Specifies the encoding of the file being read. Default value: utf-8. The following values are supported:
- nop: No encoding validation. Treats the file as a stream of raw bytes
- utf-8: UTF-8 encoding
- utf-8-raw: UTF-8 encoding without replacing invalid UTF-8 bytes
- utf-16le: UTF-16 encoding with little-endian byte order
- utf-16be: UTF-16 encoding with big-endian byte order
- ascii: ASCII encoding
- big5: The Big5 Chinese character encoding
Poll interval: The duration between filesystem polls, for example: 1s, 5m, 1h. Default value: 200ms
Initial buffer size: The initial size (in KiB) of the buffer to read file headers and logs. The buffer will grow as needed; larger values may cause unnecessary memory allocation, while smaller values may require multiple copies during growth. Default value: 16KiB
Max log size: Maximum size of a log entry in megabytes. Larger log entries will be truncated. Default value: 1MiB
Max batches: Maximum number of batches to keep in memory; applicable only when more than 1024 files match the File pattern.
Retry on failure max elapsed time: Maximum time (including retries) to send a log batch to a downstream consumer before discarding it, for example: 1s, 5m, 1h. Retrying never stops if set to 0. Default value 0
Compression: Specifies the compression format of the files being read. Possible values are the empty string, gzip, and auto. Use auto when your File pattern matches a mix of compressed and uncompressed files.
Start at: Specifies where to start reading logs on startup: beginning or end of the file. Default value: beginning

2.2 - Windows Event Log

Collect logs from the Event Log of the host.

Add new Event Log Collector

To create a new Collection Rule that collects data from files on edge hosts, complete the following steps:

Select Sources > Collection Rules > Create New Rule. (Alternatively, you can select Add Collector > Create a collection rule on the Collectors page of an edge host.)
Select Windows Event Log.
Configure the connector rule.
1. Enter a name for the collection rule into the Rule Name field.
2. (Optional) Add labels to the collection rule.
  
  You can use these metrics labels as:
  - Filter labels on the Analytics page
  - in the Filter By Label field during log tapping
  - in Flow Processing steps, for example, in the Query field of Select Messages steps.
3. Set the Edge Selector for the collection rule. The selector determines which edge hosts will have an edge connector based on this collection rule.
  - Only edge hosts will match the rule.
  - If you leave the Edge Selector field empty, the rule will match every edge host.
  - To select only a specific host, set the name field to the name of the host as selector.
  - If you set multiple fields in the selector, the collection rule will apply only to edge hosts that match all elements of the selector. (There in an AND relationship between the fields.) For example, label.location = us-east-1 AND label.product = windows
4. (Optional) Enter a Suffix for the collection rule. This suffix will be used in the name of the edge connector instances created on the edge hosts. For example, if the name of a matching edge host is “my-edge”, and the suffix of the rule is “otel-file-collector”, the edge connector created for the edge will be named “my-edge-otel-file-collector”.
  
  If the Suffix field is empty, the name of the collection rule is used instead.
5. (Optional) Enter a description for the rule.

Set how to collect the event logs:

To collect data from the following channels, select Channels, then the channels you want to collect data from: Application, System, Security, Setup, ForwardedEvents.

Alternatively, select Query and set a custom XML query to collect the data, for example:

<QueryList>
    <Query Id="0">
        <Select Path="Application">
            *[System[(Level <= 3) and 
            TimeCreated[timediff(@SystemTime) <= 86400000]]]
        </Select>
        <Suppress Path="Application">
            *[System[(Level = 2)]]
        </Suppress>
        <Select Path="System">
            *[System[(Level=1  or Level=2 or Level=3) and 
            TimeCreated[timediff(@SystemTime) <= 86400000]]]
        </Select>
    </Query>
</QueryList>

(Optional) If needed, set advanced options under More options.
Select Create. Based on the collection rule, Axoflow automatically creates edge connectors on the edge hosts that match the Edge Selector.

CAUTION:
Make sure to configure Data Forwarding Rules for your edge hosts to transfer the collected data to an AxoRouter.

You can use these metrics labels as:

Filter labels on the Analytics page
in the Filter By Label field during log tapping
in Flow Processing steps, for example, in the Query field of Select Messages steps.

label	value
edge_connector_name	The name of the edge connector that collected the message
edge_connector_type	`windowsEventLog`
edge_connector_label_	Labels set on the edge connector. By default: `vendor:microsoft`, `product:windows-event-log`
edge_connector_rule_id	The ID of the owner ConnectorRule resource in Axoflow that created the edge connector.
edge_flow_name	The name of the edge forwarding rule that sent the message.

Advanced options

Max reads: The maximum number of records to read, before beginning a new batch.
Poll interval: The duration between filesystem polls, for example: 1s, 5m, 1h. Default value: 200ms
Retry on failure max elapsed time: Maximum time (including retries) to send a log batch to a downstream consumer before discarding it, for example: 1s, 5m, 1h. Retrying never stops if set to 0. Default value 0
Start at: Specifies where to start reading logs on startup: beginning or end of the file. Default value: beginning
Ignore channel errors: If enabled, the connector keeps working if it cannot open an event log channel.
Raw: If disabled, the body of the emitted log records will contain a structured representation of the event. If enabled, the body will be the original XML string.
Include log.record.original: If enabled, log.record.original is added to the attributes of the event. This stores the original XML string as configured in Suppress rendering info.
Suppress rendering info: If disabled, additional syscalls may be made to retrieve detailed information about the event. If enabled, some unresolved values may be present in the event.

2.3 - Windows Event Tracing

Collect logs from Event Tracing for Windows (ETW).

Add new ETW Collector

To create a new Collection Rule that collects Event Tracing data from on edge hosts, complete the following steps:

Select Sources > Collection Rules > Create New Rule. (Alternatively, you can select Add Collector > Create a collection rule on the Collectors page of an edge host.)
Select Windows Event Tracing.
Configure the connector rule.
1. Enter a name for the collection rule into the Rule Name field.
2. (Optional) Add labels to the collection rule.
  
  You can use these metrics labels as:
  - Filter labels on the Analytics page
  - in the Filter By Label field during log tapping
  - in Flow Processing steps, for example, in the Query field of Select Messages steps.
3. Set the Edge Selector for the collection rule. The selector determines which edge hosts will have an edge connector based on this collection rule.
  - Only edge hosts will match the rule.
  - If you leave the Edge Selector field empty, the rule will match every edge host.
  - To select only a specific host, set the name field to the name of the host as selector.
  - If you set multiple fields in the selector, the collection rule will apply only to edge hosts that match all elements of the selector. (There in an AND relationship between the fields.) For example, label.location = us-east-1 AND label.product = windows
4. (Optional) Enter a Suffix for the collection rule. This suffix will be used in the name of the edge connector instances created on the edge hosts. For example, if the name of a matching edge host is “my-edge”, and the suffix of the rule is “otel-file-collector”, the edge connector created for the edge will be named “my-edge-otel-file-collector”.
  
  If the Suffix field is empty, the name of the collection rule is used instead.
5. (Optional) Enter a description for the rule.
Select the configuration profile to use. The following profiles are available:
- DNS server (full trace): A pre-defined profile for collecting every available DNS server traces.
- DNS server (queries only): A pre-defined profile for collecting only DNS queries.
- Custom: Use a fully-customized configuration.
(Optional) If needed, set advanced options under More options.

Note that if you set an advanced option when using a pre-defined profile, your changes override the related default setting of the pre-defined profile.
Select Create. Based on the collection rule, Axoflow automatically creates edge connectors on the edge hosts that match the Edge Selector.

CAUTION:
Make sure to configure Data Forwarding Rules for your edge hosts to transfer the collected data to an AxoRouter.

Note When using Log tapping, ETW events look a bit weird: the body of these events is empty. That’s normal, the reason for that is that everything is sent as metadata.

You can use these metrics labels as:

Filter labels on the Analytics page
in the Filter By Label field during log tapping
in Flow Processing steps, for example, in the Query field of Select Messages steps.

label	value
edge_connector_name	The name of the edge connector that collected the message
edge_connector_type	`windowsEventTracing`
edge_connector_label_	Labels set on the edge connector. By default: `vendor:microsoft`, `product:windows-event-tracing`
edge_connector_rule_id	The ID of the owner ConnectorRule resource in Axoflow that created the edge connector.
edge_flow_name	The name of the edge forwarding rule that sent the message.

Advanced options

Note that if you set an advanced option when using a pre-defined profile, your changes override the related default setting of the pre-defined profile.

Provider: The provider to subscribe to, for example, Microsoft-Windows-DNSServer for DNS logs. For a complete list, open a command prompt on the edge host and run logman query providers.

Note that provider name is case sensitive. Alternatively, you can use the GUID of the provider as well, in the following format: {9e814aad-3204-11d2-9a82-006008a86939}. If you’re manually setting the provider, consider enabling the Ignore missing provider option as well.
Level: Log level of trace events to be included. Specifying a log level means that all higher priority log levels will be collected as well. Possible values are (starting with the highest priority): critical, error, warning, information, verbose.
Ignore missing provider: Continue working if the specified provider is missing from the host.

CAUTION:
If this option is disabled and the provider is missing, the all other connectors of the agent can stop, not just the ETW connectors.
Match any keywords: Collect only traces that match at least one of the specified keywords of the provider. Note that these keywords are not literal strings, but bitmasks that correspond to the specific provider. To match on multiple keywords, you have to add the bitmasks of the corresponding keywords.
Match all keywords: Collect only traces that match all of the specified keywords of the provider. Note that these keywords are not literal strings, but bitmasks that correspond to the specific provider. To match on multiple keywords, you have to add the bitmasks of the corresponding keywords.
Buffer size: Buffer size allocated for each ETW trace session, in kilobytes. Minimum is 4, maximum is 16384.
Minimum buffers: Minimum number of buffers allocated for each ETW trace session. Note that the minimum and maximum buffers behave like hints to the ETW subsystem and aren’t guaranteed to be allocated as specified.
Maximum buffers: Maximum number of buffers allocated for each ETW trace session. Note that the minimum and maximum buffers behave like hints to the ETW subsystem and aren’t guaranteed to be allocated as specified.
Flush time: How often, in seconds, any non-empty trace buffers are flushed. 0 will enable a default timeout of 1 second.
Event buffer size: Number of ETW events the ETW receiver stores in memory for processing.
Number of workers: Number of workers that process ETW events.

3 - Data forwarding from edge hosts

To send data from an edge host to an AxoRouter, create a data forwarding rule.

Sources are hosts that are sending data to a data aggregator, like AxoRouter.
Edges are source hosts that are running a collector agent managed by Axoflow Console, or have an Axolet agent reporting metrics from the host.

Note Collection rules and data forwarding rules are currently supported on Windows hosts.

Data forwarding rules are high-level policies that determine how data should be forwarded from a set of edge hosts to an AxoRouter’s OpenTelemetry connector. You can use dynamic host labels to specify the edge hosts that the forwarding rule applies to.

To see every data forwarding rule configured in Axoflow Console, select Sources > Forwarding Rules from the main menu.

Data forwarding rules list

Data forwarding rules have the following main elements:

the edge selector, which determines the list of edge hosts that will create a data forwarding rule based on that rule.

You can use any labels and metadata of the edge hosts in the edge selectors, for example, the hostname, or any custom labels. For example, using the label.product = windows selector will create an edge connector only on Windows hosts.
the Router connector to send the data to. This must be an OpenTelemetry connector of an AxoRouter.

Selecting a data forwarding rule shows the details of the rule, including the list of Matched edges.

Create data forwarding rule

To create a new data forwarding rule, complete the following steps.

Select Sources > Forwarding Rules > Create New Rule.
Enter a name for the collection rule into the Rule Name field.
(Optional) Enter a description for the rule.
Set the Edge Selector for the rule. The selector determines which edge hosts will have data forwarding configured based on this rule.
- Only edge hosts will match the rule.
- If you leave the Edge Selector field empty, the rule will match every edge host.
- To select only a specific host, set the name field to the name of the host as selector.
- If you set multiple fields in the selector, the collection rule will apply only to edge hosts that match all elements of the selector. (There in an AND relationship between the fields.) For example, label.location = us-east-1 AND label.product = windows
Select the OpenTelemetry connector of an AxoRouter where you want to send the data.
Select Create to create and immediately apply the data forwarding rule to the matching edge hosts. Alternatively, select Create as draft to create the rule in a disabled state. You can enable the rule later on the Data Sources > Forwarding Rules page.

Modify forwarding rule

To modify an existing data forwarding rule, complete the following steps.

Note

You cannot directly modify the data forwarding settings of an edge host, only via modifying a data forwarding rule.
Modifying a rule affects every edge host that matches the Edge Selector of the rule.
To apply an existing rule to a new edge host, you can:
- Add a label to the edge host so the Edge Selector of the rule matches the new host, and/or
- Change the Edge Selector of the rule to match the new host.

Find the data forwarding rule you want to modify:
- Select Sources > Forwarding Rules from the main menu, then select the rule you want to modify.
- Alternatively, find the edge host whose data forwarding you want to modify on the Topology page, then select Forwarding Rules. Find the rule you want to modify, click on its name to display its details, then select Edit.
Modify the configuration of the data forwarding rule as needed.

CAUTION:
The changes are applied immediately after you click Update. Double-check your changes to avoid losing data.
Select Update.

Add edge host to existing forwarding rule

To add an edge host to an existing data forwarding rule, you have two options, depending on the Edge Selector of the data forwarding rule:

Modify the Edge Selector field of the rule to include the new edge host.
Modify the labels of the edge host so it matches the edge selector of the rule.

4 - AxoRouter connector rules

Connectors define the methods and entry points where AxoRouter receives data from the sources. To collect data from edge hosts, see Edge collection rules.

In addition to providing a simple protocol specific listener, Connectors implement critical processing steps - for example classification and parsing - right at the ingestion point to enrich data before it gets processed by Flows.

On top of this, Connector rules are high-level policies that determine what kind of Connectors should be available on a set of AxoRouter instances based on dynamic host labels.

To see every connector rule configured in Axoflow Console, select Routers > Connector Rules from the main menu.

Connector rules list

Connector rules have the following main elements:

the way they accept data (for example, via syslog, using the OpenTelemetry protocol), and other protocol-specific parameters (for example, port number)
the router selector, which determines the list of AxoRouter instances that will create a connector based on that rule.

You can use any labels and metadata of the AxoRouter hosts in the Router selectors, for example, the hostname of the AxoRouter, or any custom labels. For example, using the label.wec = enabled selector on a Windows Event Collector (WEC) rule will create a WEC connector on AxoRouter hosts that have the wec label set to enabled.

Selecting a connector rule shows the details of the connector rule, including the list of Matched hosts: the AxoRouter deployments that will have a connector based on that connector rule. If you click on the name of a matched router, the Connectors page of the AxoRouter host opens, showing you the connectors configured for that host.

Create connector rule

To create a new connector rule, complete the following steps.

Select Routers > Connector Rules > Create New Rule. (Alternatively, you can select Add Connector > Create a connector rule on the Connectors page of an AxoRouter host.)
Select the type of connector you want to create. For example, OpenTelemetry. The following connector types are available:
Configure the connector rule.
1. Enter a name for the connector rule into the Rule Name field.
2. (Optional) Add labels to the connector rule. You will be able to use these labels in Flow Processing steps, for example, in the Query field of Select Messages steps. For details about the message schema and the related connector-specific fields, see the meta.connector object.
3. Set the Router Selector for the connector rule. The selector determines which AxoRouter instances will have a connector based on this connector rule.
  - If you leave the Router Selector field empty, the rule will match every AxoRouter instance.
  - To select only a specific AxoRouter instance, set the name field to the name of the instance as selector.
  - If you set multiple fields in the selector, the connector rule will apply only to AxoRouter instances that match all elements of the selector. (There in an AND relationship between the fields.)
4. (Optional) Enter a Suffix for the connector rule. This suffix will be used in the name of the connector instances created on the AxoRouter hosts. For example, if the name of a matching AxoRouter instance is “my-axorouter”, and the suffix of the rule is “otlp-rule”, the connector created for the AxoRouter will be named “my-axorouter-otlp-rule”.
  
  If the Suffix field is empty, the name of the connector rule is used instead.
5. (Optional) Enter a description for the rule.
6. If needed, enable the Classify and Parse preprocessing steps so AxoRouter automatically identifies and parses messages sent by supported data sources. If your source is not listed, contact us.
  
  Enabling these options processes all data received by the connectors created based on this connector rule. If you want to apply classification and parsing more selectively, you can use the Classify and Parse processing steps in your Flows.
  
  Note that the Parse processing step requires Classify to be enabled. Parsing automatically parses the data from the content of the message, and replaces the message content (the log.body field in the internal message schema) with the structured information.
7. (Optional) If needed, you can add other preprocessing steps to the connector rule. You can use the same processing steps as in flows. These can be useful if you use a dedicated connector rule to fix or annotate data coming from some specific sources.
Configure the protocol-specific settings. For details, see the specific pages:
Select Create.

Axoflow automatically creates connectors on the AxoRouter hosts that match the Router Selector.

Make sure to enable the ports you’ve configured in the connector on the firewall of the AxoRouter host, and on other firewalls between the AxoRouter host and your data sources.

Modify connector rule

To modify an existing connector rule, complete the following steps.

Note

You cannot directly modify the connector of an AxoRouter host, only via modifying a connector rule.
Modifying a connector rule affects every AxoRouter that matches the Router Selector of the rule.
To apply an existing connector rule to a new AxoRouter instance, you can:
- Add a label to the AxoRouter host so the Router Selector of the connector rule matches the new host, and/or
- Change the Router Selector of the connector rule to match the new host.

Find the connector rule you want to modify:
- Select Routers > Connector Rules from the main menu, then select the connector rule you want to modify.
- Alternatively, find the AxoRouter instance whose connector you want to modify on the Topology page, then select Connector Rules. Find the connector you want to modify, then select ⋮ > Edit connector rule.
Modify the configuration of the connector rule as needed.

CAUTION:
The changes are applied immediately after you click Update. Double-check your changes to avoid losing data.
Select Update.

Add AxoRouter to existing connector rule

To add an AxoRouter to an existing connector rule, you have two options, depending on the Router Selector of the connector rule:

Modify the Router Selector field of the connector rule to include the new AxoRouter host.
Modify the labels of the AxoRouter host so it matches the router selector of the connector rule.

5 - OpenTelemetry

Receive logs, metrics, and traces from OpenTelemetry clients over the OpenTelemetry Protocol (OTLP/gRPC).

Prerequisites

If you want to enable TLS encryption for this connector to encrypt the communication with the sources, you’ll need to set appropriate keys and certificates.

CAUTION:

Copy the keys and certificates to AxoRouter before starting to configure the connector. Otherwise, you won’t be able to make configuration changes that require reloading the AxoRouter service, including starting log tapping or flow tapping.

Note the following points:

Keys and certificates must be in PEM format.
If the file contains a certificate chain, the file must begin with the certificate of the host, followed by the CA certificate that signed the certificate of the host, and any other signing CAs in order.
You must manually copy these files to their place on the AxoRouter host, currently you can’t distribute them from Axoflow Console.

The files must be readable by the axorouter service.
The recommended path for certificates is under /etc/axorouter/user-config/ (for example, /etc/axorouter/user-config/tls-key.pem). (If you need to use a different path, you have to append an option like -v /your/path:/your/path to the AXOROUTER_PODMAN_ARGS variable of /etc/axorouter/container.env.)
When referring to the key or certificate during when configuring the connector, use absolute paths (for example, /etc/axorouter/user-config/tls-key.pem).

Add new OpenTelemetry connector

To add a new connector to an AxoRouter host, complete the following steps:

Select Routers > Connector Rules > Create New Rule. (Alternatively, you can select Add Connector > Create a connector rule on the Connectors page of an AxoRouter host.)
Select OpenTelemetry.
Configure the connector rule.
1. Enter a name for the connector rule into the Rule Name field.
2. (Optional) Add labels to the connector rule. You will be able to use these labels in Flow Processing steps, for example, in the Query field of Select Messages steps. For details about the message schema and the related connector-specific fields, see the meta.connector object.
3. Set the Router Selector for the connector rule. The selector determines which AxoRouter instances will have a connector based on this connector rule.
  - If you leave the Router Selector field empty, the rule will match every AxoRouter instance.
  - To select only a specific AxoRouter instance, set the name field to the name of the instance as selector.
  - If you set multiple fields in the selector, the connector rule will apply only to AxoRouter instances that match all elements of the selector. (There in an AND relationship between the fields.)
4. (Optional) Enter a Suffix for the connector rule. This suffix will be used in the name of the connector instances created on the AxoRouter hosts. For example, if the name of a matching AxoRouter instance is “my-axorouter”, and the suffix of the rule is “otlp-rule”, the connector created for the AxoRouter will be named “my-axorouter-otlp-rule”.
  
  If the Suffix field is empty, the name of the connector rule is used instead.
5. (Optional) Enter a description for the rule.
6. If needed, enable the Classify and Parse preprocessing steps so AxoRouter automatically identifies and parses messages sent by supported data sources. If your source is not listed, contact us.
  
  Enabling these options processes all data received by the connectors created based on this connector rule. If you want to apply classification and parsing more selectively, you can use the Classify and Parse processing steps in your Flows.
  
  Note that the Parse processing step requires Classify to be enabled. Parsing automatically parses the data from the content of the message, and replaces the message content (the log.body field in the internal message schema) with the structured information.
7. (Optional) If needed, you can add other preprocessing steps to the connector rule. You can use the same processing steps as in flows. These can be useful if you use a dedicated connector rule to fix or annotate data coming from some specific sources.
If needed, configure the port number where you want to receive data.
Configure TLS settings for the connector.
1. Select Server TLS.
2. Set the path to the key and certificates.
  
  When using TLS, set the paths for the certificates and keys used for the TLS-encrypted communication with the clients. For details, see Prerequisites.
  - Server certificate path: The certificate that AxoRouter shows to the clients.
  - Server private key path: The private key of the server certificate.
  - CA certificate path: The CA certificate that AxoRouter uses to verify the certificate of the destination if Verify peer certificate is enabled.
3. To require the certificates of the clients to be valid, select Verify client certificate. When selected, the certificate of the client cannot be self-signed, and its common name must match the hostname or IP address of the client.
Select Create.

Axoflow automatically creates connectors on the AxoRouter hosts that match the Router Selector.

Make sure to enable the ports you’ve configured in the connector on the firewall of the AxoRouter host, and on other firewalls between the AxoRouter host and your data sources.

Labels

label	value
connector.type	`otlp`
connector.name	The Name of the connector
connector.port	The port number where the connector receives data

6 - Syslog

The Syslog connector can receive all kinds of syslog messages. You can configure it to receive data on specific ports, and apply parsing, classification, and enrichment to the messages, in addition to standard syslog parsing.

Prerequisites

If you want to enable TLS encryption for this connector to encrypt the communication with the sources, you’ll need to set appropriate keys and certificates.

CAUTION:

Note the following points:

Keys and certificates must be in PEM format.
If the file contains a certificate chain, the file must begin with the certificate of the host, followed by the CA certificate that signed the certificate of the host, and any other signing CAs in order.
You must manually copy these files to their place on the AxoRouter host, currently you can’t distribute them from Axoflow Console.

The files must be readable by the axorouter service.
The recommended path for certificates is under /etc/axorouter/user-config/ (for example, /etc/axorouter/user-config/tls-key.pem). (If you need to use a different path, you have to append an option like -v /your/path:/your/path to the AXOROUTER_PODMAN_ARGS variable of /etc/axorouter/container.env.)
When referring to the key or certificate during when configuring the connector, use absolute paths (for example, /etc/axorouter/user-config/tls-key.pem).

Add new syslog connector

To create a new syslog connector, complete the following steps:

Select Routers > Connector Rules > Create New Rule. (Alternatively, you can select Add Connector > Create a connector rule on the Connectors page of an AxoRouter host.)
Select Syslog.
Select the template to use one of the standard syslog ports and networking protocols, for example, UDP 514 for the RFC3164 syslog protocol.

To configure a different port, or to specify the protocol elements manually, select Custom.
Configure the connector rule.
1. Enter a name for the connector rule into the Rule Name field.
2. (Optional) Add labels to the connector rule. You will be able to use these labels in Flow Processing steps, for example, in the Query field of Select Messages steps. For details about the message schema and the related connector-specific fields, see the meta.connector object.
3. Set the Router Selector for the connector rule. The selector determines which AxoRouter instances will have a connector based on this connector rule.
  - If you leave the Router Selector field empty, the rule will match every AxoRouter instance.
  - To select only a specific AxoRouter instance, set the name field to the name of the instance as selector.
  - If you set multiple fields in the selector, the connector rule will apply only to AxoRouter instances that match all elements of the selector. (There in an AND relationship between the fields.)
4. (Optional) Enter a Suffix for the connector rule. This suffix will be used in the name of the connector instances created on the AxoRouter hosts. For example, if the name of a matching AxoRouter instance is “my-axorouter”, and the suffix of the rule is “otlp-rule”, the connector created for the AxoRouter will be named “my-axorouter-otlp-rule”.
  
  If the Suffix field is empty, the name of the connector rule is used instead.
5. (Optional) Enter a description for the rule.
6. If needed, enable the Classify and Parse preprocessing steps so AxoRouter automatically identifies and parses messages sent by supported data sources. If your source is not listed, contact us.
  
  Enabling these options processes all data received by the connectors created based on this connector rule. If you want to apply classification and parsing more selectively, you can use the Classify and Parse processing steps in your Flows.
  
  Note that the Parse processing step requires Classify to be enabled. Parsing automatically parses the data from the content of the message, and replaces the message content (the log.body field in the internal message schema) with the structured information.
7. (Optional) If needed, you can add other preprocessing steps to the connector rule. You can use the same processing steps as in flows. These can be useful if you use a dedicated connector rule to fix or annotate data coming from some specific sources.
Select the protocol to use for receiving syslog data: TCP, UDP, or TLS.

When using TLS, set the paths for the certificates and keys used for the TLS-encrypted communication with the clients. For details, see Prerequisites.
- CA certificate path: The CA certificate that AxoRouter uses to authenticate the clients.
- Server certificate path: The certificate that AxoRouter shows to the clients.
- Server private key path: The private key of the server certificate.
(Optional) If explicitly needed for your use case, you can configure Framing manually. Otherwise, leave it on Auto. Enable framing (On) if the payload contains the length of the message as specified in RFC6587 3.4.1. Disable (Off) for non-transparent-framing RFC6587 3.4.2.
Set the Port of the connector. The port number must be unique on the AxoRouter host. Axoflow Console will not provision a connector to an AxoRouter if it would cause a port collision, but other software on the given host may already be using the chosen port number (for example, an SSH server on TCP port 22). In this case, AxoRouter won’t be able to reload the configuration and it will indicate an error.
(Optional) If you’re expecting high-volume UDP traffic on your AxoRouter instances that will have this connector, enable UDP loadbalancing by entering the number of UDP sockets to use into the UDP socket count field. The maximum recommended value is the number of cores available in the AxoRouter host.

UDP loadbalancing in AxoRouter is based on eBPF. Note that if you enable loadbalancing, messages of the same high-traffic source may be processed out of order. For details on how eBPF loadbalancing works, see the Scaling syslog to 1M EPS with eBPF blog post.
(Optional) If needed for your environment, set protocol-specific connector options as needed.

You can also modify the product and vendor labels of the connector. In that case, Axoflow will treat the incoming messages as it was received and classified as data from the specified product. This is useful if you want to send data from a specific product to a dedicated port.

These labels and other parameters of the connector will be available under the meta.connector key as metadata for the messages received via the connector, and can be used in routing decisions and processing steps. You can check the metadata of the messages using log tapping.
Select Create.

Axoflow automatically creates connectors on the AxoRouter hosts that match the Router Selector.

Make sure to enable the ports you’ve configured in the connector on the firewall of the AxoRouter host, and on other firewalls between the AxoRouter host and your data sources.

Protocol-specific connector options

Encoding: The character set of the messages, for example, UTF-8.
Maximum connections: The maximum number of simultaneous connections the connector can receive.
Socket buffer size: The size of the socket buffer (in bytes).
- Processing workers: Number of worker threads to use to process the messages received by the source connector. Note that this enables parallel processing, which might cause that the messages will be processed out of order. Increasing the number of worker threads can drastically improve the performance of the source. For details, see the AxoSyslog documentation.

Flow-control options

Initial log window size: The size (number of messages) of the initial window used in flow control. For details, see the AxoSyslog documentation.
Log fetch limit: The maximum number of messages fetched from a source during a single poll loop. For details, see the AxoSyslog documentation.

TCP options

TCP Keepalive Time Interval: The interval (number of seconds) between subsequential keepalive probes, regardless of the traffic exchanged in the connection.
TCP Keepalive Probes: The number of unacknowledged probes to send before considering the connection dead.
TCP Keepalive Time: The interval (in seconds) between the last data packet sent and the first keepalive probe.

TLS options

For TLS, you can use the TCP-specific options, and also the following:

Require MTLS: If enabled, the peers must have a TLS certificate, otherwise AxoRouter will reject the connection.
Verify client certificate: If enabled, AxoRouter verifies certificate of the peer, and rejects connections with invalid certificates.

Labels

The AxoRouter syslog connector adds the following meta labels:

label	value
connector.type	`syslog`
connector.name	The Name of the connector
connector.port	The port number where the connector receives data

7 - Webhook

Webhook connectors of AxoRouter can be used to receive log events through HTTP(S) POST requests.

You can specify static and dynamic URLs to receive the data. AxoRouter automatically parses the JSON payload of the request, and adds it to the log.body field of the message as a JSON object. Other types of payload (including invalid JSON objects) is added to the log.body field as a string. Note that you can add further parsing to the body using processing steps in Flows, for example, using FilterX or Regex processing steps.

Prerequisites

To receive data via HTTPS, you’ll need a key and a certificate that the connector will show to the clients.

If you want to enable TLS encryption for this connector to encrypt the communication with the sources, you’ll need to set appropriate keys and certificates.

CAUTION:

Note the following points:

Keys and certificates must be in PEM format.
If the file contains a certificate chain, the file must begin with the certificate of the host, followed by the CA certificate that signed the certificate of the host, and any other signing CAs in order.
You must manually copy these files to their place on the AxoRouter host, currently you can’t distribute them from Axoflow Console.

The files must be readable by the axorouter service.
The recommended path for certificates is under /etc/axorouter/user-config/ (for example, /etc/axorouter/user-config/tls-key.pem). (If you need to use a different path, you have to append an option like -v /your/path:/your/path to the AXOROUTER_PODMAN_ARGS variable of /etc/axorouter/container.env.)
When referring to the key or certificate during when configuring the connector, use absolute paths (for example, /etc/axorouter/user-config/tls-key.pem).

Add new webhook connector

To add a new connector to an AxoRouter host, complete the following steps:

Select Routers > Connector Rules > Create New Rule. (Alternatively, you can select Add Connector > Create a connector rule on the Connectors page of an AxoRouter host.)
Select Webhook.
Configure the connector rule.
1. Enter a name for the connector rule into the Rule Name field.
2. (Optional) Add labels to the connector rule. You will be able to use these labels in Flow Processing steps, for example, in the Query field of Select Messages steps. For details about the message schema and the related connector-specific fields, see the meta.connector object.
3. Set the Router Selector for the connector rule. The selector determines which AxoRouter instances will have a connector based on this connector rule.
  - If you leave the Router Selector field empty, the rule will match every AxoRouter instance.
  - To select only a specific AxoRouter instance, set the name field to the name of the instance as selector.
  - If you set multiple fields in the selector, the connector rule will apply only to AxoRouter instances that match all elements of the selector. (There in an AND relationship between the fields.)
4. (Optional) Enter a Suffix for the connector rule. This suffix will be used in the name of the connector instances created on the AxoRouter hosts. For example, if the name of a matching AxoRouter instance is “my-axorouter”, and the suffix of the rule is “otlp-rule”, the connector created for the AxoRouter will be named “my-axorouter-otlp-rule”.
  
  If the Suffix field is empty, the name of the connector rule is used instead.
5. (Optional) Enter a description for the rule.
6. If needed, enable the Classify and Parse preprocessing steps so AxoRouter automatically identifies and parses messages sent by supported data sources. If your source is not listed, contact us.
  
  Enabling these options processes all data received by the connectors created based on this connector rule. If you want to apply classification and parsing more selectively, you can use the Classify and Parse processing steps in your Flows.
  
  Note that the Parse processing step requires Classify to be enabled. Parsing automatically parses the data from the content of the message, and replaces the message content (the log.body field in the internal message schema) with the structured information.
7. (Optional) If needed, you can add other preprocessing steps to the connector rule. You can use the same processing steps as in flows. These can be useful if you use a dedicated connector rule to fix or annotate data coming from some specific sources.
Select the protocol you want to use: HTTPS or HTTP.
Set the port number where the webhook will receive the POST requests, for example, 8080.
Set the endpoints where the webhook will receive data in the Paths field. You can use static paths, or regular expressions. In regular expressions you can use named capture groups to automatically set macro values in AxoRouter. For example, the /events/(?P<HOST>.*) path sets the hostname for the data received in the request based on the second part of the URL: a request to the /events/my-example-host URL sets the host field of that message to my-example-host.

By default, the /events and /events/(?P<HOST>.*) paths are active.
For HTTPS endpoints, set the path to the Key and the Certificate files. AxoRouter uses these to encrypt the TLS channel. You can use absolute paths (for example, /etc/axorouter/user-config/tls-key.pem). The key and the certificate must be in PEM format.

You must manually copy these files to their place, currently you can’t distribute them from Axoflow.
Select Create.

Axoflow automatically creates connectors on the AxoRouter hosts that match the Router Selector.

Make sure to enable the ports you’ve configured in the connector on the firewall of the AxoRouter host, and on other firewalls between the AxoRouter host and your data sources.
Send a test request to the webhook.
1. Open the Overview tab of the AxoRouter host where you’ve created the webhook connector and check the IP address or FQDN of the host.
2. Open a terminal on your computer and send a POST request to the path you’ve configured in the webhook.
```
curl -X POST -H 'Content-Type: application/json' --data '{"host":"myhost", "body": "sample webhook message" }' <;router-IP-address>:<webhook-port-number>/<webhook-path>/
```
  For example, if you’ve used the default values of the webhook connector you can use:
```
curl -X POST -H 'Content-Type: application/json' --data '{"host":"myhost", "body": "sample webhook message" }' <;router-IP-address>/events/
```
  Expected output:
```
{"status": "received"}
```

Note You can also use Log tapping on the AxoRouter host to see the incoming messages. Tapping into the data received by the webhook connector

Metadata fields

The AxoRouter webhook connector adds the following fields to the meta variable:

field	value
meta.connector.type	`webhook`
meta.connector.name	`<name of the connector>`
meta.connector.port	`<port of the connector>`
meta.connector.labels.product	Default value: `webhook`
meta.connector.labels.vendor	Default value: `generic`

8 - Windows Event Collector (WEC)

The AxoRouter Windows Events connector can receive Windows Event Logs by running a Windows Event Collector (WEC) server. After enabling the Windows Events connector, you can configure your Microsoft Windows hosts to forward their event logs to AxoRouter using Windows Event Forwarding (WEF).

Windows Event Forwarding (WEF) reads any operational or administrative event logged on a Windows host and forwards the events you choose to a Windows Event Collector (WEC) server - in this case, AxoRouter.

Prerequisites

When using TLS authentication, you’ll need a

CA certificate (in PEM format) that AxoRouter uses to authenticate the clients.
A certificate and the matching private key (in PEM format) that AxoRouter shows to the clients.

These files must be available on the AxoRouter host, and readable by the axorouter service for the connector to work.

Add new Windows Event Log connector

To add a new connector to an AxoRouter host, complete the following steps.

Note Currently you can configure one Windows Events connector for an AxoRouter.

Select Routers > Connector Rules > Create New Rule. (Alternatively, you can select Add Connector > Create a connector rule on the Connectors page of an AxoRouter host.)
Select Windows Events.
Configure the connector rule.
1. Enter a name for the connector rule into the Rule Name field.
2. (Optional) Add labels to the connector rule. You will be able to use these labels in Flow Processing steps, for example, in the Query field of Select Messages steps. For details about the message schema and the related connector-specific fields, see the meta.connector object.
3. Set the Router Selector for the connector rule. The selector determines which AxoRouter instances will have a connector based on this connector rule.
  - If you leave the Router Selector field empty, the rule will match every AxoRouter instance.
  - To select only a specific AxoRouter instance, set the name field to the name of the instance as selector.
  - If you set multiple fields in the selector, the connector rule will apply only to AxoRouter instances that match all elements of the selector. (There in an AND relationship between the fields.)
4. (Optional) Enter a Suffix for the connector rule. This suffix will be used in the name of the connector instances created on the AxoRouter hosts. For example, if the name of a matching AxoRouter instance is “my-axorouter”, and the suffix of the rule is “otlp-rule”, the connector created for the AxoRouter will be named “my-axorouter-otlp-rule”.
  
  If the Suffix field is empty, the name of the connector rule is used instead.
5. (Optional) Enter a description for the rule.
6. If needed, enable the Classify and Parse preprocessing steps so AxoRouter automatically identifies and parses messages sent by supported data sources. If your source is not listed, contact us.
  
  Enabling these options processes all data received by the connectors created based on this connector rule. If you want to apply classification and parsing more selectively, you can use the Classify and Parse processing steps in your Flows.
  
  Note that the Parse processing step requires Classify to be enabled. Parsing automatically parses the data from the content of the message, and replaces the message content (the log.body field in the internal message schema) with the structured information.
7. (Optional) If needed, you can add other preprocessing steps to the connector rule. You can use the same processing steps as in flows. These can be useful if you use a dedicated connector rule to fix or annotate data coming from some specific sources.
Configure the protocol-level settings of the connector.
1. (Optional) Set the Hostname field. The clients will address this hostname. Note that:
  - This is the hostname that is configured as the Subscription Manager address in the Group Policy Editor.
  - If unset, the server will automatically detect it from the request’s host header.
2. (Optional) If for some reason don’t want to run the connection on the default port (5986), adjust the Port field.
3. Set the paths for the certificates and keys used for the TLS-encrypted communication with the clients.
  
  Use absolute paths (for example, /etc/axorouter/user-config/tls-key.pem). The key and the certificate must be in PEM format. You have to make sure that these files are available on the AxoRouter host, currently you can’t distribute them from Axoflow Console.
  - CA certificate path: The CA certificate that AxoRouter uses to authenticate the clients. If you want to limit which clients are accepted, set the More options > Certificate subject filter field.
  - Server certificate path: The certificate that AxoRouter shows to the clients. The Common Name must match the hostname used by the clients to contact the server.
  - Server private key path: The private key of the server certificate.
4. (Optional) If needed, set the number of workers.
  - Processing workers: Number of worker threads to use to process the messages received by the source connector. Note that this enables parallel processing, which might cause that the messages will be processed out of order. Increasing the number of worker threads can drastically improve the performance of the source. For details, see the AxoSyslog documentation.
Configure the subscriptions of the connector.
1. Select Add new Subscription.
2. (Optional) Set a name for the subscription. If you leave it empty, Axoflow Console automatically generates a name.
3. Enter the event filter query into the Query field. This query specifies which events are collected by the subscription. For details on the query syntax, see the Microsoft documentation.
  
  A single query can retrieve events from a maximum of 256 different channels.
  
  For example, the following example queries every event from the Security, System, Application, and Setup channels.
```
<QueryList>
  <Query Id="0">
    <Select Path="Application">*</Select>
    <Select Path="Security">*</Select>
    <Select Path="Setup">*</Select>
    <Select Path="System">*</Select>
  </Query>
</QueryList>
```
4. (Optional) If needed, you can configure other low-level options in the More options section. For details, see Additional options.
Select Create.

Axoflow automatically creates connectors on the AxoRouter hosts that match the Router Selector.

Make sure to enable the ports you’ve configured in the connector on the firewall of the AxoRouter host, and on other firewalls between the AxoRouter host and your data sources.
Configure Windows Event Forwarding (WEF) on your clients to forward their events to the AxoRouter WEC connector.

When configuring the Subscription Manager address in the Group Policy Editor, use the hostname you’ve set in the connector

Additional options

You can set the following options of the WEC connector under Subscriptions > More options.

WEC more settings

Certificate subject filter: A simple string to filter the clients based on the Common Name of their certificate. You can use the * and ? wildcard characters.
UUID: A unique ID for the subscription. If empty, Axoflow Console automatically generates it.
Heartbeat interval: The number of seconds, before the client will send a heartbeat message. The client sends heartbeat messages if it has no new events to send. Default value: 3600s
Connection retry interval: Time between reconnection attempts. Default value: 60s
Connection retry count: Number of times the client will attempt to reconnect if AxoRouter is unreachable. Default value: 10
Max time: The maximum number of seconds the client aggregates new events before sending them in a batch. Default value: 30s
Max elements: The maximum number of events that the client aggregates before sending them in a batch. By default it’s empty, meaning that only the Max time and Max envelope size options limit the aggregation. Default value: empty
Max envelope size: The maximum number of bytes in the SOAP envelope used to deliver the events. Default value: 512000 bytes
Locale: The language in which rendering information is expected, for example, en-US. Default value: Client choose
Data locale: The language in which numerical data is expected to be formatted, for example, en-US. Default value: Client choose
Read existing events: If enabled (Yes), the event source sends:
- all existing events that match the filter, and
- any events that subsequently occur for that event source.
If disabled (No), existing events will be ignored.

Default value: No
Ignore channel error: Subscription queries that result in errors will terminate the processing of the clients. Enable this option to ignore such errors. Default value: Yes
Content format: Determines whether to include rendering information (RenderedText) with events or not (Raw). Default value: Raw

Metadata fields

The AxoRouter Windows Events connector adds the following fields to the meta variable:

field	value
meta.connector.type	`windowsEvents`
meta.connector.name	`<name of the connector>`
meta.connector.port	`<port of the connector>`

9 - Vendors

Prerequisites

You have administrative access to the source device or host.
You have an AxoRouter deployed and configured with a Syslog connector that has parsing and classification enabled (by default, every AxoRouter has such connectors). This device is going to receive the data from the source device or host.
You know the IP address the AxoRouter. To find it:
1. Open the Axoflow Console.
2. Select the Routers or the Topology page.
3. Select on AxoRouter instance that is going to receive the logs.
4. Check the Networks > Address field.

Steps

To onboard a source that is specifically supported by Axoflow, complete the following steps. Onboarding allows you to collect metrics about the host, and display the host on the Topology page.

Open the Axoflow Console.
Select Topology.
Select Create New Item > Source.
If the source is already sending logs to an AxoRouter instance that is registered in the Axoflow Console, select Detected, then select the source.

Otherwise, select the type of the source you want to onboard, and follow the on-screen instructions.
Connect the source to the destination or AxoRouter instance it’s sending logs to.
1. Select Topology > Create New Item > Path.
2. Select your data source in the Source host field.
3. Select the target router or aggregator this source is sending its data to in the Target host field, for example, axorouter.
4. Select the Target connector. The connector determines how the destination receives the data (for example, using which protocol or port).
5. Select Create. The new path appears on the Topology page.
Configure the source to send logs to an AxoRouter instance. Specific instructions regarding individual vendors are listed below, along with default metadata (labels) and specific metadata for Splunk.
Note
Unless instructed otherwise, configure your source to send the logs to the Syslog connector of AxoRouter, using the appropriate port. Use RFC5424 if the source supports it.
- 514 UDP and TCP for RFC3164 (BSD-syslog) and RFC5424 (IETF-syslog) formatted traffic. AxoRouter automatically recognizes and handles both formats.
- 601 TCP for RFC5424 (IETF-syslog) and RFC3164 (BSD-syslog) formatted traffic. AxoRouter automatically recognizes and handles both formats.
- 6514 TCP for TLS-encrypted syslog traffic.

9.1 - A10 Networks

9.1.1 - vThunder

vThunder: Delivers application load balancing, traffic management, and DDoS protection for enterprise networks.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	a10networks
product	vthunder
format	cef

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
a10networks:vThunder:cef	a10networks:vThunder	netwaf

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: A10_LOAD_BALANCER.

9.2 - Amazon

9.2.1 - CloudWatch

CloudWatch: Monitors AWS resources and applications by collecting metrics, logs, and setting alarms.

Axoflow can collect data from your Amazon CloudWatch. At a high level, the process looks like this:

Deploy an Axoflow Cloud Connector that will collect the data from your CloudWatch. Axoflow Cloud Connector is a simple container that you can deploy into AWS, another cloud provider, or on-prem.
The connector forwards the collected data to the OpenTelemetry connector of an AxoRouter instance. This AxoRouter can be deployed within AWS, another cloud provider, or on-prem.
Configure a Flow on Axoflow Console that processes and routes the collected data to your destination (for example, Splunk or another SIEM).

Prerequisites

An AWS account with an active subscription.
A virtual machine or Kubernetes node running to deploy Axoflow Cloud Connector on.
An AxoRouter instance that can receive data from the connector. Verify that it has an OpenTelemetry Connector (it’s enabled by default).
You know the IP address the AxoRouter. To find it:
1. Open the Axoflow Console.
2. Select the Routers or the Topology page.
3. Select on AxoRouter instance that is going to receive the logs.
4. Check the Networks > Address field.
The Axoflow Cloud Connector must be able to access the AxoRouter on the port the OpenTelemetry Connector is listening on (by default, port 4317). Depending on where the Axoflow Cloud Connector and AxoRouter are deployed, you might need to adjust firewall and ingress/egress rules in your environment.
Depending on how you want to authenticate Axoflow Cloud Connector, you’ll need an AWS_PROFILE or AWS access keys.

Steps

To collect data from AWS CloudWatch, complete the following steps.

Deploy an Axoflow Cloud Connector.

Access the Kubernetes node or virtual machine where you want to deploy Axoflow Cloud Connector.
Set the following environment variable to the IP address of the AxoRouter where you want to forward the data from CloudWatch. This IP address must be accessible from the connector. You can find the IP address of AxoRouter on the Routers > AxoRouter > Overview page.
```
export AXOROUTER_ENDPOINT=<AxoRouter-IP-address>
```
(Optional) By default, the connector stores positional and other persistence-related data in the /etc/axoflow-otel-collector/storage directory. In case you want to use a different directory, set the STORAGE_DIRECTORY environment variable.

Run the following command to generate a UUID for the connector. Axoflow Console will use this ID to identify the connector.

UUID_FULL=$(uuidgen 2>/dev/null || cat /proc/sys/kernel/random/uuid 2>/dev/null || python3 -c "import uuid; print(uuid.uuid4())")
export AXOCLOUDCONNECTOR_DEVICE_ID=$(echo "$UUID_FULL" | cut -d'-' -f1)

Set TLS encryption to secure the communication between Axoflow Cloud Connector and AxoRouter.

Configure the TLS-related settings of Axoflow Cloud Connector using the following environment variables.

Variable	Required	Default	Description
`AXOROUTER_TLS_INSECURE`	No	`false`	Disables TLS encryption if set to `true`
`AXOROUTER_TLS_INCLUDE_SYSTEM_CA_CERTS_POOL`	No	`false`	Set to `true` to use the system CA certificates
`AXOROUTER_TLS_CA_FILE`	No	-	Path to the CA certificate file used to validate the certificate of AxoRouter
`AXOROUTER_TLS_CA_PEM`	No	-	PEM-encoded CA certificate
`AXOROUTER_TLS_INSECURE_SKIP_VERIFY`	No	`false`	Set to `true` to disable TLS certificate verification of AxoRouter
`AXOROUTER_TLS_CERT_FILE`	No	-	Path to the certificate file of Axoflow Cloud Connector
`AXOROUTER_TLS_CERT_PEM`	No	-	PEM-encoded client certificate
`AXOROUTER_TLS_KEY_FILE`	No	-	Path to the client private key file of Axoflow Cloud Connector
`AXOROUTER_TLS_KEY_PEM`	No	-	PEM-encoded client private key
`AXOROUTER_TLS_MIN_VERSION`	No	`1.2`	Minimum TLS version to use
`AXOROUTER_TLS_MAX_VERSION`	No	-	Maximum TLS version to use

Note You’ll have to include the TLS-related environment variables you set in the docker command used to deploy Axoflow Cloud Connector.

Configure the authentication that the Axoflow Cloud Connector will use to access CloudWatch. Set the environment variables for the authentication method you want to use.
- AWS Profile with a configuration file: Set the region and the AWS_PROFILE
```
export AWS_PROFILE=""
export AWS_REGION=""
```
- AWS Credentials: To use AWS access keys, set an access key and a matching secret.
```
export AWS_ACCESS_KEY_ID=""
export AWS_SECRET_ACCESS_KEY=""
export AWS_REGION=""
```
- EC2 instance profile:
```
export AWS_REGION=""
```

Deploy the Axoflow Cloud Connector. The exact command depends on the authentication method and the TLS settings you want to configure.

AWS Profile with a configuration file: Set the region and the AWS_PROFILE. Also, pass the TLS-related settings you’ve set earlier.

docker run --rm \
-v "${STORAGE_DIRECTORY}":"${STORAGE_DIRECTORY}" \
-e AWS_PROFILE="${AWS_PROFILE}" \
-e AWS_REGION="${AWS_REGION}" \
-e AWS_SDK_LOAD_CONFIG=1 \
-e AXOROUTER_ENDPOINT="${AXOROUTER_ENDPOINT}" \
-e STORAGE_DIRECTORY="${STORAGE_DIRECTORY}" \
-e AXOCLOUDCONNECTOR_DEVICE_ID="${AXOCLOUDCONNECTOR_DEVICE_ID}" \
-e <TlS-related-environment-variable>="${<TlS-related-environment-variable>}" \
-v "${HOME}/.aws:/cloudconnectors/.aws:ro" \
ghcr.io/axoflow/axocloudconnectors:latest

AWS Credentials: To use AWS access keys, set an access key and a matching secret. Also, pass the TLS-related settings you’ve set earlier.

docker run --rm \
-v "${STORAGE_DIRECTORY}":"${STORAGE_DIRECTORY}" \
-e AWS_ACCESS_KEY_ID="${AWS_ACCESS_KEY_ID}" \
-e AWS_SECRET_ACCESS_KEY="${AWS_SECRET_ACCESS_KEY}" \
-e AWS_REGION="${AWS_REGION}" \
-e AXOROUTER_ENDPOINT="${AXOROUTER_ENDPOINT}" \
-e AXOCLOUDCONNECTOR_DEVICE_ID="${AXOCLOUDCONNECTOR_DEVICE_ID}" \
-e <TlS-related-environment-variable>="${<TlS-related-environment-variable>}" \
-e STORAGE_DIRECTORY="${STORAGE_DIRECTORY}" \
ghcr.io/axoflow/axocloudconnectors:latest

EC2 instance profile: Also, pass the TLS-related settings you’ve set earlier.

docker run --rm \
-v "${STORAGE_DIRECTORY}":"${STORAGE_DIRECTORY}" \
-e AWS_REGION="${AWS_REGION}" \
-e AXOROUTER_ENDPOINT="${AXOROUTER_ENDPOINT}" \
-e AXOCLOUDCONNECTOR_DEVICE_ID="${AXOCLOUDCONNECTOR_DEVICE_ID}" \
-e <TlS-related-environment-variable>="${<TlS-related-environment-variable>}" \
-e STORAGE_DIRECTORY="${STORAGE_DIRECTORY}" \
ghcr.io/axoflow/axocloudconnectors:latest

The Axoflow Cloud Connector starts forwarding logs to the AxoRouter instance.

Add the appliance to Axoflow Console.
1. Open the Axoflow Console and select Topology.
2. Select Create New Item > Source.
3. Select AWS CloudWatch.
4. Enter the IP address and the FQDN of the Axoflow Cloud Connector instance.
5. Select Create.
Create a Flow to route the data from the AxoRouter instance to a destination. You can use the Labels of this source to select messages from this source.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	amazon
product	aws-cloudwatch
format	otlp

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
aws:cloudwatchlogs	aws-activity

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: AWS_CLOUDWATCH.

9.3 - Axoflow

9.3.1 - AxoSyslog

AxoSyslog: High-performance, configurable syslog service for collecting, processing, and forwarding log data.

Configure AxoSyslog to send data to an OpenTelemetry Connector of an AxoRouter instance using its syslog-ng-otlp destination. If that’s not possible for some reason, use the syslog-ng destination with a Syslog Connector of an AxoRouter instance.

For the best integration of your AxoSyslog instances with Axoflow Console, see AxoSyslog.

Labels

Enable classification and parsing in the connector rule that receives data from this source. Axoflow will identify the messages and add labels accordingly.

9.4 - Broadcom

9.4.1 - Edge Secure Web Gateway (Edge SWG)

Edge Secure Web Gateway (Edge SWG): Secures web traffic through policy enforcement, SSL inspection, and real-time threat protection.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	broadcom
product	edge-swg
service	bluecoat, ProxySG

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
bluecoat:proxysg:access:syslog	netops
bluecoat:proxysg:access:kv	netproxy

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: BROADCOM_EDGE_SWG.

Earlier name/vendor

Blue Coat Proxy
Blue Coat ProxySG
Symantec ProxySG
Symantec Edge Secure Web Gateway
Symantec Edge SWG

9.4.2 - NSX

NSX: Provides network virtualization, micro-segmentation, and security for software-defined data centers.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Configure your NSX appliances, NSX Edges, and hypervisors to send their logs to the Syslog (autodetect and classify) connector of an AxoRouter instance. Use either:

The TCP protocol (port 601 when using the default connector), or
TLS-encrypted TCP protocol (port 6514 when using the default connector)

For details on configuring NSX, see Configure Remote Logging in the NSX Administration Guide.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	broadcom
product	nsx
service	NSX, NSXV, FIREWALL-PKTLOG, dfwpktlogs

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
vmware:nsxlog:dfwpktlogs	netfw
vmware:nsxlog:firewall-pktlog	netfw
vmware:nsxlog:nsx	infraops
vmware:nsxlog:nsxv	infraops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: VMWARE_NSX.

Earlier name/vendor

VMware NSX
NSX-T Data Center

9.5 - Check Point

9.5.1 - Anti-Bot

Anti-Bot: Detects and blocks botnet communications and command-and-control traffic to prevent malware infections.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	anti-bot

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:endpoint	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CHECKPOINT_EDR.

9.5.2 - Anti-Malware

Anti-Malware: Protects endpoints from viruses, ransomware, and other malware using signature and behavior analysis.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	anti-malware

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:endpoint	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CHECKPOINT_EDR.

9.5.3 - Anti-Phishing

Anti-Phishing: Prevents phishing attacks by analyzing email content and links to block credential theft attempts.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	anti-phishing

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:email	email

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CHECKPOINT_EMAIL.

9.5.4 - Anti-Spam and Email Security

Anti-Spam and Email Security: Blocks spam and malicious email content using reputation checks and email filtering techniques.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	antispam-emailsecurity

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:email	email

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CHECKPOINT_EMAIL.

9.5.5 - CPMI Client

CPMI Client: Legacy Check Point management client used to interface with security policies and logs.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	cpmi-client

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cp_log	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CHECKPOINT_FIREWALL.

9.5.6 - cpmidu_update_tool

cpmidu_update_tool: Utility used to update configuration and database files for Check Point Multi-Domain environments.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	cpmidu-update-tool

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:audit	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CHECKPOINT_FIREWALL.

9.5.7 - Database Tool

Database Tool: Command-line tool to extract, query, or update Check Point configuration and policy databases.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	database-tool

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:audit	netops

9.5.8 - Edge Secure Web Gateway (Edge SWG)

Edge Secure Web Gateway (Edge SWG): Provides configuration profiles for secure mobile access and web filtering on iOS devices.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	ios-profiles

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:network	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CHECKPOINT_HARMONY.

9.5.9 - Endpoint Compliance

Endpoint Compliance: Checks endpoint status and posture before granting network access, enforcing security policies.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	endpoint-compliance

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:endpoint	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CHECKPOINT_EDR.

9.5.10 - Endpoint Management

Endpoint Management: Centralized platform for managing endpoint protection, updates, and policy enforcement.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	endpoint-management

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:endpoint	netops

9.5.11 - Forensics

Forensics: Analyzes security incidents on endpoints to uncover attack vectors and malicious activity.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	forensics

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:endpoint	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CHECKPOINT_EDR.

9.5.12 - GO Password Reset

GO Password Reset: Facilitates secure password reset processes for users across integrated environments.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	go-password-reset

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:audit	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CHECKPOINT_AUDIT.

9.5.13 - HTTPS Inspection

HTTPS Inspection: Decrypts and inspects HTTPS traffic to detect hidden threats within encrypted web sessions.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	https-inspection
service	CP-GW

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:firewall	netfw

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CHECKPOINT_FIREWALL.

9.5.14 - IPS

IPS: Detects and blocks known and unknown exploits, malware, and vulnerabilities in network traffic.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	ips

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:ids	netids

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CHECKPOINT_EDR.

9.5.15 - MDS Query Tool

MDS Query Tool: CLI tool for querying multi-domain configurations and policies in Check Point environments.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	mds-query-tool

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cp_log	netops

9.5.16 - Media Encryption & Port Protection

Media Encryption & Port Protection: Secures USB ports and encrypts removable media to protect sensitive data on endpoints.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	media-port

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:endpoint	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CHECKPOINT_EDR.

9.5.17 - Mobile Access

Mobile Access: Enables secure remote access to corporate apps and data from mobile devices.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	mobile-access

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:network	netops

9.5.18 - Next-Generation Firewall (NGFW)

Next-Generation Firewall (NGFW): Next-generation firewall providing intrusion prevention, application control, and threat protection.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	firewall
service	CP-GW

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:firewall	netfw

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CHECKPOINT_FIREWALL.

9.5.19 - QoS

QoS: Implements bandwidth control and traffic prioritization policies for optimized network usage.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	qos

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:firewall	netfw

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CHECKPOINT_FIREWALL.

9.5.20 - Quantum

Quantum: Unified threat prevention platform delivering firewall, VPN, and intrusion prevention capabilities.

If you’d like to send data from this source to AxoRouter, contact our support team for details.

9.5.21 - Query Database

Query Database: Accesses and queries internal policy or object databases in Check Point systems.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	query-database

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:audit	netops

9.5.22 - SmartConsole

SmartConsole: Graphical interface for managing Check Point security policies, logs, and monitoring.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	smartconsole

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:audit	netops

9.5.23 - SmartUpdate

SmartUpdate: Tool for updating and managing licenses, software, and hotfixes in Check Point environments.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	smartupdate

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:audit	netops

9.5.24 - Threat Emulation and Anti-Exploit

Threat Emulation and Anti-Exploit: Emulates files in a virtual environment to detect and block advanced persistent threats and exploits.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	threat-emulation

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:endpoint	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CHECKPOINT_EDR.

9.5.25 - URL Filtering

URL Filtering: Controls and logs web access based on URL categories and custom site rules to enforce policy.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	url-filtering
service	CP-GW

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:firewall	netfw

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CHECKPOINT_FIREWALL.

9.5.26 - Web API

Web API: Provides programmatic access to Check Point security management through RESTful API endpoints.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	checkpoint
product	web-api

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cp_log	checkpoint:audit	netops

9.6 - Cisco

9.6.1 - Access Control System (ACS)

Access Control System (ACS): Centralizes network access control with RADIUS and TACACS+ for authentication and authorization.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cisco
product	acs
service	CSCOacs_Single_Authentications, CSCOacs_Multi_Authentications

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cisco:acs	netauth

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CISCO_ACS.

9.6.2 - Adaptive Security Appliance (ASA)

Adaptive Security Appliance (ASA): Provides stateful firewall, VPN support, and advanced threat protection for secure network perimeters.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cisco
product	asa
format	text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cisco:asa	netfw

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CISCO_ASA_FIREWALL.

9.6.3 - Application Control Engine (ACE)

Application Control Engine (ACE): Provides application-aware load balancing, SSL offload, and traffic control for Cisco networks.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cisco
product	ace
format	text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cisco:ace	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CISCO_ACE.

9.6.4 - Cisco IOS

Cisco IOS: Network operating system for Cisco routers and switches, enabling routing, switching, and security.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cisco
product	ios
format	text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cisco:ios	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CISCO_IOS.

9.6.5 - Digital Network Architecture (DNA)

Digital Network Architecture (DNA): Provides software-defined networking, policy automation, and analytics for enterprise infrastructure.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cisco
product	dna
service	DNAC
format	text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cisco:dna	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CISCO_DNAC.

9.6.6 - Email Security Appliance (ESA)

Email Security Appliance (ESA): Protects email systems from spam, phishing, malware, and data loss with advanced threat filtering.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cisco
product	esa
service	amp, antispam, content_scanner, error_logs, ESA, euq_logs, gui_logs, mail_logs, service_logs, reportd_logs, smartlicense, sntpd_logs, updater_logs
format	text-plain \| cef

Note that the device can be configured to send plain syslog text or CEF-formatted output.

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype, index, and source settings:

sourcetype	index	source
cisco:esa:http	email	esa:http
cisco:esa:textmail	email	esa:textmail
cisco:esa:amp	email	esa:amp
cisco:esa:antispam	email	esa:antispam
cisco:esa:system_logs	email	esa:system_logs
cisco:esa:system_logs	email	esa:euq_logs
cisco:esa:system_logs	email	esa:service_logs
cisco:esa:system_logs	email	esa:reportd_logs
cisco:esa:system_logs	email	esa:sntpd_logs
cisco:esa:system_logs	email	esa:smartlicense
cisco:esa:error_logs	email	esa:error_logs
cisco:esa:error_logs	email	esa:updater_logs
cisco:esa:content_scanner	email	esa:content_scanner
cisco:esa:authentication	email	esa:authentication
cisco:esa:http	email	esa:http
cisco:esa:textmail	email	esa:textmail
cisco:esa:amp	email	esa:amp
cisco:esa	email	program: <variable>
cisco:esa:cef	email	esa:consolidated

Tested with: Splunk Add-on for Cisco ESA

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CISCO_EMAIL_SECURITY.

9.6.7 - Firepower

Firepower: Provides next-gen firewall features including intrusion prevention, app control, and malware protection.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cisco
product	firepower
service	SFIMS
format	text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cisco:firepower:syslog	netids

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CISCO_FIREPOWER_FIREWALL.

9.6.8 - Firepower Threat Defence (FTD)

Firepower Threat Defence (FTD): Unifies firewall, VPN, and intrusion prevention into a single software for comprehensive threat defense.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cisco
product	ftd
format	text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cisco:ftd	netfw

9.6.9 - Firewall Services Module (FWSM)

Firewall Services Module (FWSM): Delivers multi-context, high-performance firewall services integrated into Cisco Catalyst switches.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cisco
product	fwsm
format	text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cisco:fwsm	netfw

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CISCO_FWSM.

9.6.10 - HyperFlex (HX, UCSH)

HyperFlex (HX, UCSH): Infrastructure solution combining compute, storage, and networking in a single system.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cisco
product	ucsh
service	hx-audit-rest, hx-device-connector, hx-ssl-access
format	text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cisco:ucsh:hx	infraops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CISCO_UCS.

9.6.11 - Identity Services Engine (ISE)

Identity Services Engine (ISE): Manages network access control and enforces policies with user and device authentication capabilities.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

For details on configuring your Identity Services Engine to forward its logs to an AxoRouter instance, see Configure Remote Syslog Collection Locations in Cisco Identity Services Engine (ISE) Administrator Guide.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cisco
product	ise
service	CISE_Alarm, CISE_Passed_Authentications, CISE_RADIUS_Accounting, CISE_System_Statistics

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cisco:ise:syslog	netauth

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CISCO_ISE.

9.6.12 - Integrated Management Controller (IMC)

Integrated Management Controller (IMC): Provides out-of-band server management for Cisco UCS, enabling hardware monitoring and configuration.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cisco
product	cimc
format	text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cisco:cimc	infraops

9.6.13 - IOS XR

IOS XR: High-performance, modular network operating system for carrier-grade routing and scalability.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cisco
product	xr
service	config, nfsvr, plat_sl_client, ssh_syslog_proxy
format	text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cisco:xr	netops

9.6.14 - Meraki MX

Meraki MX: Cloud-managed network appliance offering firewall, VPN, SD-WAN, and security in a single platform.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cisco
product	meraki
format	text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cisco:meraki	netfw

Tested with: TA-meraki

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CISCO_MERAKI.

9.6.15 - Private Internet eXchange (PIX)

Private Internet eXchange (PIX): Legacy firewall appliance delivering stateful inspection and secure network access control.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cisco
product	pix
format	text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cisco:pix	netfw

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CISCO_PIX_FIREWALL.

9.6.16 - TelePresence Video Communication Server (VCS)

TelePresence Video Communication Server (VCS): Enables video conferencing control and call routing for Cisco TelePresence systems and endpoints.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cisco
product	tvcs
service	tvcs
format	text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cisco:tvcs	main

9.6.17 - Unified Computing System Manager (UCSM)

Unified Computing System Manager (UCSM): Centralized management platform for Cisco Unified Computing System (UCS) servers and resources.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cisco
product	ucsm
format	text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cisco:ucs	infraops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CISCO_UCS.

9.6.18 - Unified Communications Manager (UCM)

Unified Communications Manager (UCM): Delivers unified voice, video, messaging, and mobility services in enterprise IP telephony systems.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cisco
product	ucm
format	text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cisco:ucm	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CISCO_UCM.

9.6.19 - Viptela

Viptela: Software-defined WAN solution providing secure connectivity, centralized control, and traffic optimization.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cisco
product	viptela
service	SYSMGR
format	text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cisco:viptela	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CISCO_VIPTELA.

9.7 - Citrix

9.7.1 - Netscaler

Netscaler: Offers application delivery, load balancing, and security features for optimized app performance.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	citrix
product	netscaler
service	svm_service
format	cef \| text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
citrix:netscaler:appfw:cef	netfw
citrix:netscaler:syslog	netfw
citrix:netscaler:appfw	netfw

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CITRIX_NETSCALER_WEB_LOGS.

9.8 - Corelight

9.8.1 - Open Network Detection & Response (NDR)

Open Network Detection & Response (NDR): Provides network detection and response by analyzing traffic for advanced threats and anomalous behavior.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	corelight
product	ndr-platform

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype, source, and index settings:

sourcetype	index
corelight_alerts	main
corelight_conn	main
corelight_corelight	main
corelight_corelight_metrics_bro	main
corelight_corelight_metrics_iface	main
corelight_dhcp	main
corelight_dpd	main
corelight_etc_viz	main
corelight_evt_all	main
corelight_evt_http	main
corelight_evt_suri	main
corelight_files	main
corelight_ftp	main
corelight_http	main
corelight_http_red	main
corelight_idx	main
corelight_irc	main
corelight_kerberos	main
corelight_metrics_bro	main
corelight_metrics_iface	main
corelight_rdp	main
corelight_smb	main
corelight_smb_files	main
corelight_socks	main
corelight_ssh	main
corelight_ssh_red	main
corelight_ssl	main
corelight_st_base	main
corelight_suri	main
corelight_suricata_corelight	main
corelight_x509	main

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CORELIGHT.

9.9 - CyberArk

9.9.1 - Privileged Threat Analytics (PTA)

Privileged Threat Analytics (PTA): Analyzes privileged account behavior to detect threats and suspicious activity in real time.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cyberark
product	pta
format	cef

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cyberark:pta:cef	main

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CYBERARK_PTA.

9.9.2 - Vault

Vault: Stores and manages privileged credentials, session recordings, and access control policies securely.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	cyberark
product	vault
format	cef

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
cyberark:epv:cef	netauth

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: CYBERARK.

9.10 - F5 Networks

9.10.1 - BIG-IP

BIG-IP: Provides load balancing, traffic management, and application security for optimized service delivery.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	f5
product	bigip
service	ASM, apmd, audit_forwarder, CROND, F5, httpd, mcpd, sshd, sshd(pam_audit), systemd-journal, tmm, tmm1, tmm2, tmsh
format	text-plain \| JSON \| kv

Note that the device can be configured to send plain syslog text, JSON, or key-value pairs.

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
f5:bigip:syslog	netops
f5:bigip:ltm:access_json	netops
f5:bigip:asm:syslog	netops
f5:bigip:apm:syslog	netops
f5:bigip:ltm:ssl:error	netops
f5:bigip:ltm:tcl:error	netops
f5:bigip:ltm:traffic	netops
f5:bigip:ltm:log:error	netops
f5:bigip:gtm:dns:request:irule	netops
f5:bigip:gtm:dns:response:irule	netops
f5:bigip:ltm:http:irule	netops
f5:bigip:ltm:failed:irule	netops
nix:syslog	netops

Tested with: Splunk Add-on for F5 BIG-IP

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: F5_BIGIP_APM.

9.11 - FireEye

9.12 - Forcepoint

9.12.1 - Email Security

Email Security: Protects email systems from spam, phishing, malware, and data exfiltration using advanced threat defense.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	forcepoint
product	email

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype, source, and index settings:

sourcetype	index
forcepoint:email:cef	email
forcepoint:email:kv	email
forcepoint:email:leef	email

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: FORCEPOINT_EMAILSECURITY.

Earlier name/vendor

Websense Email Security

9.12.2 - Next-Generation Firewall (NGFW)

Next-Generation Firewall (NGFW): Next-gen firewall with deep packet inspection, policy enforcement, and integrated intrusion prevention.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	forcepoint
product	firewall

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype, source, and index settings:

sourcetype	index
websense:cg:cef	netproxy

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: FORCEPOINT_FIREWALL.

Earlier name/vendor

Websense Webprotect
Forcepoint Webprotect
Forcepoint Secure Web Gateway

9.12.3 - WebProtect

WebProtect: Provides web traffic filtering, malware protection, and data loss prevention for secure internet access.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	forcepoint
product	webprotect

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype, source, and index settings:

sourcetype	index
websense:cg:cef	netproxy
websense:cg:kv	netproxy
websense:cg:leef	netproxy

Earlier name/vendor

Websense Firewall

9.13 - Fortinet

9.13.1 - FortiGate firewalls

FortiGate firewalls: Enterprise firewall platform offering threat protection, VPN, and traffic filtering for secure networking.

The following sections show you how to configure FortiGate Next-Generation Firewall (NGFW) to send their log data to Axoflow.

CAUTION:

Prerequisites

You have administrative access to the firewall.
The date, time, and time zone are correctly set on the firewall.
You have an AxoRouter deployed and configured with a Syslog connector that has parsing and classification enabled (by default, every AxoRouter has such connectors). This device is going to receive the data from the firewall.
You know the IP address the AxoRouter. To find it:
1. Open the Axoflow Console.
2. Select the Routers or the Topology page.
3. Select on AxoRouter instance that is going to receive the logs.
4. Check the Networks > Address field.

Steps

Note: The steps involving the FortiGate user interface are just for your convenience, for details, see the official FortiGate documentation.

Log in to your FortiGate device. You need administrator privileges to perform the configuration.
Register the address of your AxoRouter as an Address Object.
1. Select Log & Report > Log Settings > Global Settings.
2. Configure the following settings:
  - Event Logging: Click All.
  - Local traffic logging: Click All.
  - Syslog logging: Enable this option.
  - IP address/FQDN: Enter the address of your AxoRouter: %axorouter-ip%
3. Click Apply.
Add the source to Axoflow Console.
1. Open the Axoflow Console and select Topology.
2. Select Create New Item > Source.
  - If the source is actively sending data to an AxoRouter instance, select Detected, then select your source.
  - Otherwise, select the vendor and product corresponding to your source from the Predefined sources, then enter the parameters of the source, like IP address and FQDN.
  Note During log tapping, you can add hosts that are actively sending data to an AxoRouter instance by clicking Register source.
3. (Optional) Add custom labels as needed.
4. Select Create.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	fortinet
product	fortigate
service	fortigate
format	kv

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
fortigate_event	netops
fortigate_traffic	netfw
fortigate_utm	netfw

Tested with: Fortinet FortiGate Add-On for Splunk technical add-on

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: FORTINET_FIREWALL.

9.13.2 - FortiMail

FortiMail: Secures inbound and outbound email with spam filtering, malware protection, and advanced threat detection.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	fortinet
product	fortimail
service	fortiweb
format	kv

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
fml:log	email

Tested with: FortiMail Add-on for Splunk technical add-on

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: FORTINET_FORTIMAIL.

9.13.3 - FortiWeb

FortiWeb: Web application firewall protecting websites from attacks like XSS, SQL injection, and bot threats.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	fortinet
product	fortiweb
service	fortiweb
format	kv

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
fwb_log	netops
fwb_attack	netids
fwb_event	netops
fwb_traffic	netfw

Tested with: Fortinet FortiWeb Add-0n for Splunk technical add-on

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: FORTINET_FORTIWEB.

9.14 - Fortra

9.14.1 - Powertech SIEM Agent for IBM i

Powertech SIEM Agent for IBM i: Monitors IBM i system activity and forwards security events for centralized analysis in SIEM platforms.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	forta
product	powertech-siem-agent
format	cef
format	leef

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype, source, and index settings:

sourcetype	source	index
PowerTech:SIEMAgent:cef	PowerTech:SIEMAgent	netops
PowerTech:SIEMAgent:leef	PowerTech:SIEMAgent	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: FORTRA_POWERTECH_SIEM_AGENT.

Earlier name/vendor

Powertech Interact

9.15 - General Unix/Linux host

9.15.1 - Generic Linux services

Generic Linux services: A generic placeholder for program classifications

These classifications include non-vendor specific services and applications commonly found on Linux/Unix hosts.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	nix
product	generic
service	`bind`, `chronyd`, `cron`, `cupsd`, `dbus-daemon`, `dhcpd`, `dnsmasq`, `dnf`, `dockerd`, `NetworkManager`, `nxlog`, `rsyslogd`, `sshd`, `su`, `sudo`, `syslog-ng`, or `systemd`

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

source	sourcetype	index
program:chron	nix:syslog	netops
program:chronyd	nix:syslog	netops
program:cupsd	nix:syslog	netops
program:dbus-daemon	nix:syslog	netops
program:dhcpd	isc:dhcpd	netipam
program:dnf	nix:syslog	netops
program:dockerd	nix:syslog	netops
program:dnsmasq	nix:syslog	netdns
program:named	isc:bind:network	netdns
program:NetworkManager	nix:syslog	netops
program:nxlog	nix:syslog	netops
program:rsyslogd	nix:syslog	netops
program:sshd	nix:syslog	netops
program:su	nix:syslog	netauth
program:sudo	nix:syslog	netauth
program:syslog-ng	nix:syslog	netops
program:systemd	nix:syslog	netops

Tested with: Splunk Add-on for Infoblox

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: BIND_DNS, ISC_DHCP, NIX_SYSTEM, or OPENSSH.

9.16 - Imperva

9.16.1 - Incapsula

Incapsula: Cloud-based WAF, DDoS protection, and bot mitigation service for securing web applications and APIs.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	imperva
product	incapsula
format	cef

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype, source, and index settings:

sourcetype	source	index
cef	Imperva:Incapsula	netwaf

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: IMPERVA_CEF.

9.16.2 - SecureSphere

SecureSphere: Provides on-prem web application, database, and file security with granular activity monitoring.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	imperva
product	securesphere
format	cef

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype, source, and index settings:

sourcetype	index
imperva:waf:firewall:cef	netwaf
imperva:waf:security:cef	netwaf
imperva:waf	netwaf

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: IMPERVA_SECURESPHERE.

9.17 - Infoblox

9.17.1 - NIOS

NIOS: Delivers secure DNS, DHCP, and IPAM (DDI) services with centralized network control and automation.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	infloblox
product	nios
service	named, threat-protect-log
format	cef

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index	source
infoblox:threatprotect	netids	Infoblox:NIOS
infoblox:dns	netids	Infoblox:NIOS

Tested with: Splunk Add-on for Infoblox

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: INFOBLOX, INFOBLOX_DNS.

9.18 - Ivanti

9.18.1 - Connect secure

Connect secure: Provides dynamic IP address assignment and network configuration for DHCP-enabled devices.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	ivanti
product	connect-secure
service	PulseSecure

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype, source, and index settings:

sourcetype	source	index
pulse:connectsecure		netfw
pulse:connectsecure:web		netproxy

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: IVANTI_CONNECT_SECURE.

Earlier name/vendor

Pulse Connect Secure

9.19 - Juniper

9.19.1 - Junos OS

Junos OS: Junos OS is the network operating system for Juniper physical and virtual networking and security products.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	juniper
product	junos
service	eswd, ifinfo, mcsnoopd, mgd, mib2d, rpd, RT_AAMW, RT_FLOW, RT_IDP, RT_SECINTEL, RT_UTM, tfeb0
format	text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
juniper:junos:aamw:structured	netfw
juniper:junos:firewall	netfw
juniper:junos:firewall	netids
juniper:junos:firewall:structured	netfw
juniper:junos:firewall:structured	netids
juniper:junos:idp	netids
juniper:junos:idp:structured	netids
juniper:legacy	netops
juniper:junos:secintel:structured	netfw
juniper:junos:snmp	netops
juniper:structured	netops

Tested with: Splunk Add-on for Juniper

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: JUNIPER_JUNOS.

9.20 - Kaspersky

9.20.1 - Endpoint Security

Endpoint Security: Protects endpoints from malware, ransomware, and intrusions with antivirus, firewall, and threat detection.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	kaspersky
product	endpoint_security
service	`KES
format	text-plain \| cef \| leef

Note that the device can be configured to send plain syslog text, LEEF, or CEF-formatted output.

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
kaspersky:cef	epav
kaspersky:es	epav
kaspersky:gnrl	epav
kaspersky:klau	epav
kaspersky:klbl	epav
kaspersky:klmo	epav
kaspersky:klna	epav
kaspersky:klpr	epav
kaspersky:klsr	epav
kaspersky:leef	epav
kaspersky:sysl	epav

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: KASPERSKY_ENDPOINT.

9.21 - Kubernetes

9.21.1 - NGINX Ingress

NGINX Ingress: Ingress NGINX Controller

Configure your log collector (for example, Telemetry Controller) to send data to an OpenTelemetry Connector of an AxoRouter instance using the OTLP/gRPC protocol.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	kubernetes
product	nginx
service	ingress-nginx

9.21.2 - Telemetry Controller

Telemetry Controller: Telemetry Controller

Configure Telemetry Controller to send data to an OpenTelemetry Connector of an AxoRouter instance.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	kubernetes
product	telemetry-controller
meta.kubernetes.namespace	k8s.namespace.name
kubernetes_namespace
kubernetes_container

9.22 - MicroFocus

9.23 - Microsoft

9.23.1 - Azure Event Hubs

Azure Event Hubs: Big data streaming platform to ingest and process events.

Axoflow can collect data from your Azure Event Hubs. At a high level, the process looks like this:

Deploy an Axoflow Cloud Connector that will collect the data from your Event Hub. Axoflow Cloud Connector is a simple container that you can deploy into Azure, another cloud provider, or on-prem.
The connector forwards the collected data to the OpenTelemetry connector of an AxoRouter instance. This AxoRouter can be deployed within Azure, another cloud provider, or on-prem.
Configure a Flow on Axoflow Console that processes and routes the collected data to your destination (for example, Splunk or another SIEM).

Prerequisites

An Azure account with an active subscription.
A virtual machine or Kubernetes node running to deploy Axoflow Cloud Connector on.
An AxoRouter instance that can receive data from the connector. Verify that it has an OpenTelemetry Connector (it’s enabled by default).
You know the IP address the AxoRouter. To find it:
1. Open the Axoflow Console.
2. Select the Routers or the Topology page.
3. Select on AxoRouter instance that is going to receive the logs.
4. Check the Networks > Address field.
The Axoflow Cloud Connector must be able to access the AxoRouter on the port the OpenTelemetry Connector is listening on (by default, port 4317). Depending on where the Axoflow Cloud Connector and AxoRouter are deployed, you might need to adjust firewall and ingress/egress rules in your environment.
An Event Hubs connection string.

Steps

To collect data from Azure Event Hubs, complete the following steps.

Deploy an Axoflow Cloud Connector into Azure.

Access the Kubernetes node or virtual machine.
Set the following environment variable to the IP address of the AxoRouter where you want to forward the data from Event Hubs. This IP address must be accessible from the connector. You can find the IP address of AxoRouter on the Routers > AxoRouter > Overview page.
```
export AXOROUTER_ENDPOINT=<AxoRouter-IP-address>
```
(Optional) By default, the connector stores positional and other persistence-related data in the /etc/axoflow-otel-collector/storage directory. In case you want to use a different directory, set the STORAGE_DIRECTORY environment variable.

Run the following command to generate a UUID for the connector. Axoflow Console will use this ID to identify the connector.

UUID_FULL=$(uuidgen 2>/dev/null || cat /proc/sys/kernel/random/uuid 2>/dev/null || python3 -c "import uuid; print(uuid.uuid4())")
export AXOCLOUDCONNECTOR_DEVICE_ID=$(echo "$UUID_FULL" | cut -d'-' -f1)

Set TLS encryption to secure the communication between Axoflow Cloud Connector and AxoRouter.

Configure the TLS-related settings of Axoflow Cloud Connector using the following environment variables.

Variable	Required	Default	Description
`AXOROUTER_TLS_INSECURE`	No	`false`	Disables TLS encryption if set to `true`
`AXOROUTER_TLS_INCLUDE_SYSTEM_CA_CERTS_POOL`	No	`false`	Set to `true` to use the system CA certificates
`AXOROUTER_TLS_CA_FILE`	No	-	Path to the CA certificate file used to validate the certificate of AxoRouter
`AXOROUTER_TLS_CA_PEM`	No	-	PEM-encoded CA certificate
`AXOROUTER_TLS_INSECURE_SKIP_VERIFY`	No	`false`	Set to `true` to disable TLS certificate verification of AxoRouter
`AXOROUTER_TLS_CERT_FILE`	No	-	Path to the certificate file of Axoflow Cloud Connector
`AXOROUTER_TLS_CERT_PEM`	No	-	PEM-encoded client certificate
`AXOROUTER_TLS_KEY_FILE`	No	-	Path to the client private key file of Axoflow Cloud Connector
`AXOROUTER_TLS_KEY_PEM`	No	-	PEM-encoded client private key
`AXOROUTER_TLS_MIN_VERSION`	No	`1.2`	Minimum TLS version to use
`AXOROUTER_TLS_MAX_VERSION`	No	-	Maximum TLS version to use

Note You’ll have to include the TLS-related environment variables you set in the docker command used to deploy Axoflow Cloud Connector.

Set the AZURE_EVENTHUB_CONNECTION_STRING environment variable.

export AZURE_EVENTHUB_CONNECTION_STRING="Endpoint=sb://<NamespaceName>.servicebus.windows.net/;SharedAccessKeyName=<KeyName>;SharedAccessKey=<KeyValue>;EntityPath=<EventHubName>"

Deploy the Axoflow Cloud Connector by running the following command. Also, pass the TLS-related settings you’ve set earlier.

docker run --rm \
-v "${STORAGE_DIRECTORY}":"${STORAGE_DIRECTORY}" \
-e AZURE_EVENTHUB_CONNECTION_STRING="${AZURE_EVENTHUB_CONNECTION_STRING}" \
-e AXOROUTER_ENDPOINT="${AXOROUTER_ENDPOINT}" \
-e STORAGE_DIRECTORY="${STORAGE_DIRECTORY}" \
-e <TlS-related-environment-variable>="${<TlS-related-environment-variable>}" \
-e AXOCLOUDCONNECTOR_DEVICE_ID="${AXOCLOUDCONNECTOR_DEVICE_ID}" \
ghcr.io/axoflow/axocloudconnectors:latest

The Axoflow Cloud Connector starts forwarding logs to the AxoRouter instance.

Add the appliance to Axoflow Console.
1. Open the Axoflow Console and select Topology.
2. Select Create New Item > Source.
3. Select Azure Event Hubs.
4. Enter the IP address and the FQDN of the Axoflow Cloud Connector instance.
5. Select Create.
Create a Flow to route the data from the AxoRouter instance to a destination. You can use the Labels of this source to select messages from this source.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	microsoft
product	azure-event-hubs
service	signin
format	otlp

Event Hubs Audit logs labels

label	value
vendor	microsoft
product	azure-event-hubs-audit
format	otlp

Event Hubs Provisioning logs labels

label	value
vendor	microsoft
product	azure-event-hubs-provisioning
format	otlp

label	value
vendor	microsoft
product	azure-event-hubs-signin
format	otlp

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
mscs:azure:eventhub:log	azure-activity

Configure the TLS-related settings of Axoflow Cloud Connector using the following environment variables.

Variable	Required	Default	Description
`AXOROUTER_TLS_INSECURE`	No	`false`	Disables TLS encryption if set to `true`
`AXOROUTER_TLS_INCLUDE_SYSTEM_CA_CERTS_POOL`	No	`false`	Set to `true` to use the system CA certificates
`AXOROUTER_TLS_CA_FILE`	No	-	Path to the CA certificate file used to validate the certificate of AxoRouter
`AXOROUTER_TLS_CA_PEM`	No	-	PEM-encoded CA certificate
`AXOROUTER_TLS_INSECURE_SKIP_VERIFY`	No	`false`	Set to `true` to disable TLS certificate verification of AxoRouter
`AXOROUTER_TLS_CERT_FILE`	No	-	Path to the certificate file of Axoflow Cloud Connector
`AXOROUTER_TLS_CERT_PEM`	No	-	PEM-encoded client certificate
`AXOROUTER_TLS_KEY_FILE`	No	-	Path to the client private key file of Axoflow Cloud Connector
`AXOROUTER_TLS_KEY_PEM`	No	-	PEM-encoded client private key
`AXOROUTER_TLS_MIN_VERSION`	No	`1.2`	Minimum TLS version to use
`AXOROUTER_TLS_MAX_VERSION`	No	-	Maximum TLS version to use

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: AZURE_EVENTHUB.

9.23.2 - Cloud App Security (MCAS)

Cloud App Security (MCAS): Monitors cloud app usage, detects anomalies, and enforces security policies across SaaS services.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	microsoft
product	cas
format	cef

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
cef	microsoft:cas	main

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: MICROSOFT_DEFENDER_CLOUD_ALERTS.

9.23.3 - Windows hosts

Windows hosts: Event logs from core services like security, system, DNS, and DHCP for operational and forensic analysis.

To collect event logs from Microsoft Windows hosts, Axoflow supports both agent-based and agentless methods.

For a collector agent, we recommend using the Axoflow OpenTelemetry Collector distribution. For details, see Windows host - agent based solution.
To use an agentless solution, see Windows Event Collector (WEC).

Labels

Labels assigned to data received from Windows hosts depend on how AxoRouter receives the data. For details, see Windows host - agent based solution and Windows Event Collector (WEC).

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
windows:eventlog:snare	oswin
windows:eventlog:xml	oswin

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: WINEVTLOG, WINEVTLOG_XML, WINDOWS_DHCP, WINDOWS_DNS.

9.24 - MikroTik

9.24.1 - RouterOS

RouterOS: Router operating system providing firewall, bandwidth management, routing, and hotspot functionality.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	mikrotik
product	routeros
service	forward
format	text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
routeros	netfw
routeros	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: MIKROTIK_ROUTER.

9.25 - NetFlow Logic

9.25.1 - NetFlow Optimizer

NetFlow Optimizer: Aggregates and transforms flow data (NetFlow, IPFIX) into actionable security and performance insights.

The following sections show you how to configure NetFlow Optimizer to send their log data to Axoflow.

CAUTION:

Prerequisites

You have administrative access to NetFlow Optimizer.
You have an AxoRouter deployed and configured with a Syslog connector that has parsing and classification enabled (by default, every AxoRouter has such connectors). This device is going to receive the data from NetFlow Optimizer.
You know the IP address the AxoRouter. To find it:
1. Open the Axoflow Console.
2. Select the Routers or the Topology page.
3. Select on AxoRouter instance that is going to receive the logs.
4. Check the Networks > Address field.

Steps

Note: The steps involving the NetFlow Optimizer user interface are just for your convenience, for details, see the official documentation.

Log in to NetFlow Optimizer.
Select Outputs, then click the plus sign to add an output to NetFlow Optimizer.
Configure a Syslog (UDP) output:
- Name: Enter a name for the output, for example, Axoflow.
- Address: The IP address of the AxoRouter instance where you want to send the messages.
- Port: Set this parameter to 514.
Click Save.
Add the source to Axoflow Console.
1. Open the Axoflow Console and select Topology.
2. Select Create New Item > Source.
  - If the source is actively sending data to an AxoRouter instance, select Detected, then select your source.
  - Otherwise, select the vendor and product corresponding to your source from the Predefined sources, then enter the parameters of the source, like IP address and FQDN.
  Note During log tapping, you can add hosts that are actively sending data to an AxoRouter instance by clicking Register source.
3. (Optional) Add custom labels as needed.
4. Select Create.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	netflow
product	optimizer
service	Network Conversations Monitor, SNMP Custom OID Sets Monitor, Sampling Monitor, SNMP Information Monitor, DNS Service Monitor, DNS Users Monitor, Network Subnets Monitor, Asset Access Monitor, Services Performance Monitor, Top Bandwidth Consumers for Cisco ASA, Top Traffic Destinations for Cisco ASA, Top Policy Violators for Cisco ASA, Top Hosts with most Connections for Cisco ASA, Outbound Mail Spammers Monitor, Inbound Mail Spammers Monitor, Unauthorized Mail Servers Monitor, Rejected Emails Monitor, Top Bandwidth Consumers for Palo Alto Networks Firewall, Top Traffic Destinations for Palo Alto Networks Firewall, Hosts with Most Policy Violations for Palo Alto Networks Firewall, Most Active Hosts for Palo Alto Networks Firewall, Bandwidth Consumption per Application for Palo Alto Networks Firewall, Bandwidth Consumption per Application/User for Palo Alto Networks, Top Applications Traffic Monitor, Top Applications Host Pairs Monitor, Visitors by Country, Botnet C&C Traffic Monitor, Custom Threat lists Monitor, Host Reputation Monitor, Threat Feeds Traffic Monitor, TCP Health Monitor, Network Conversations Monitor, Top Connections Monitor, Top Pairs Monitor, CBQoS Monitor, Traffic by Autonomous Systems, Top Traffic Monitor, Top Packets Monitor, SNMP Custom OID Sets Monitor, Top Bandwidth Consumers for NSX Distributed Firewall, Top Traffic Destinations for NSX Distributed Firewall, Top Policy Violators for NSX Distributed Firewall, Top Hosts with most Connections for NSX Distributed Firewall, Top Host VM:Host Pairs, Top VM:Host Traffic Monitor, AWS VPC Flow logs, Micro-segmentation Top Pairs Monitor, AWS Top Traffic Monitor, GCP VPC Flow Logs, GCP Top Traffic Monitor, Azure NSG Flow Logs, Cisco AVC Top Applications Monitor, Cisco AVC Bandwidth Consumption Monitor, Azure Top Traffic Monitor, Cisco AnyConnect Top Traffic Monitor, SNMP Traps Monitor, Auto-discovery Reporter, Top Traffic Monitor Geo City, Top Traffic Monitor Geo Country, Flow Data

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
flowintegrator	flowintegrator

9.26 - Netgate

9.26.1 - pfSense

pfSense: Open-source firewall and router platform with VPN, traffic shaping, and intrusion detection capabilities.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	netgate
product	pfsense
service	filterlog
format	csv \| text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
pfsense:filterlog	netfw
pfsense:<program>	netops

The pfsense:<program> variant is simply a generic linux event that is generated by the underlying OS on the appliance.

Tested with: TA-pfsense

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: PFSENSE.

9.27 - Netmotion

9.27.1 - Netmotion

Netmotion: Provides secure, optimized remote access with performance monitoring for mobile and distributed workforces.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	netmotion
product	netmotion
service	LocalityServer, nmreporting.exe
format	text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
netmotion:reporting	netops
netmotion:mobilityserver:nm_mobilityanalyticsappdata	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: NETMOTION.

9.28 - NETSCOUT

9.28.1 - Arbor Edge Defense (AED)

Arbor Edge Defense (AED): Edge-based DDoS protection and threat mitigation system to block attacks before they enter the network.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	netscout
product	arbor-edge
format	cef

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype, source, and index settings:

sourcetype	source	index
netscout:aed	netscout:aed	netids

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: ARBOR_EDGE_DEFENSE.

9.28.2 - Arbor Pravail (APS)

Arbor Pravail (APS): Monitors and mitigates advanced persistent threats and malware with inline packet inspection.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	netscout
product	arbor-pravail
service	arbor-networks-aps, pravail

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype, source, and index settings:

sourcetype	source	index
netscout:aps	netscout:aps	netids

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: ARBOR_EDGE_DEFENSE.

Earlier name/vendor

Arbor Networks Pravail (APS)

9.29 - OpenText

9.29.1 - ArcSight

ArcSight: SIEM platform for collecting, correlating, and analyzing security event data across IT environments.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	opentext
product	arcsight
format	cef

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype, source, and index settings:

sourcetype	source	index
cef	ArcSight:ArcSight	main

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: ARCSIGHT_CEF.

Earlier name/vendor

MicroFocus ArcSight

9.29.2 - Self Service Password Reset (SSPR)

Self Service Password Reset (SSPR): Allows users to securely reset their own passwords without IT assistance, reducing helpdesk load.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	opentext
product	sspr
service	SSPR

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype, source, and index settings:

sourcetype	index
sspr	netauth

Earlier name/vendor

NetIQ Self Service Password Reset

9.30 - Palo Alto Networks

9.30.1 - Cortex XSOAR

Cortex XSOAR: Security orchestration, automation, and response platform for threat detection and incident management.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	palo-alto-networks
product	cortex-xsoar
format	cef

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype, source, and index settings:

sourcetype	source	index
cef	tim:cef	infraops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: PAN_XSOAR.

Earlier name/vendor

Threat Intelligence Management (TIM)

9.30.2 - Palo Alto firewalls

Palo Alto firewalls: Firewall operating system delivering network security features including traffic control and threat prevention.

The following sections show you how to configure Palo Alto Networks Next-Generation Firewall devices to send their log data to Axoflow.

CAUTION:

Prerequisites

You have administrative access to the firewall.
The date, time, and time zone are correctly set on the firewall.
You have an AxoRouter deployed and configured with a Syslog connector that has parsing and classification enabled (by default, every AxoRouter has such connectors). This device is going to receive the data from the firewall.
You know the IP address the AxoRouter. To find it:
1. Open the Axoflow Console.
2. Select the Routers or the Topology page.
3. Select on AxoRouter instance that is going to receive the logs.
4. Check the Networks > Address field.

Steps

Note: The steps involving the Palo Alto Networks Next-Generation Firewall user interface are just for your convenience, for details, see the official PAN-OS® documentation.

Log in to your firewall device. You need administrator privileges to perform the configuration.
Configure a Syslog server profile.
1. Select Device > Server Profiles > Syslog.
2. Click Add and enter a Name for the profile, for example, axorouter.
3. Configure the following settings:
  - Syslog Server: Enter the IP address of your AxoRouter: %axorouter-ip%
  - Transport: Select TCP or TLS.
  - Port: Set the port to 601. (This is needed for the recommended IETF log format. If for some reason you need to use the BSD format, set the port to 514.)
  - Format: Select IETF.
  - Syslog logging: Enable this option.
4. Click OK.
Configure syslog forwarding for Traffic, Threat, and WildFire Submission logs. For details, see Configure Log Forwarding the official PAN-OS® documentation.
1. Select Objects > Log Forwarding.
2. Click Add.
3. Enter a Name for the profile, for example, axoflow.
4. For each log type, severity level, or WildFire verdict, select the Syslog server profile.
5. Click OK.
6. Assign the log forwarding profile to a security policy to trigger log generation and forwarding.
7. Select Policies > Security and select a policy rule.
8. Select Actions, then select the Log Forwarding profile you created (for example, axoflow).
9. For Traffic logs, select one or both of the Log at Session Start and Log At Session End options.
10. Click OK.
Configure syslog forwarding for System, Config, HIP Match, and Correlation logs.
1. Select Device > Log Settings.
2. For System and Correlation logs, select each Severity level, select the Syslog server profile, and click OK.
3. For Config, HIP Match, and Correlation logs, edit the section, select the Syslog server profile, and click OK.
Click Commit.
Add the source to Axoflow Console.
1. Open the Axoflow Console and select Topology.
2. Select Create New Item > Source.
  - If the source is actively sending data to an AxoRouter instance, select Detected, then select your source.
  - Otherwise, select the vendor and product corresponding to your source from the Predefined sources, then enter the parameters of the source, like IP address and FQDN.
  Note During log tapping, you can add hosts that are actively sending data to an AxoRouter instance by clicking Register source.
3. (Optional) Add custom labels as needed.
4. Select Create.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	palo-alto-networks
product	panos

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
pan:audit	netops
pan:globalprotect	netfw
pan:hipmatch	epintel
pan:traffic	netfw
pan:threat	netproxy
pan:system	netops

Tested with: Palo Alto Networks Add-on for Splunk technical add-on

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: PAN_FIREWALL.

9.31 - Ping Identity

9.31.1 - PingAccess

PingAccess: A centralized access security solution which provides secure access to applications and APIs down to the URL level

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	ping-identity
product	pingaccess

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
source.engine	pingaccess	netauth

Tested with: SecureAuth IdP Splunk App

9.32 - Powertech

9.33 - Progress

9.33.1 - Flowmon Anomaly Detection System (ADS)

Flowmon Anomaly Detection System (ADS): Detects network anomalies and threats through flow-based behavior analysis and machine learning.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	progress
product	flowmon-ads
service	ADS

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
flowmon-ads	netids

Earlier name/vendor

Flowmon Networks

9.34 - Riverbed

9.34.1 - SteelConnect

SteelConnect: WAN optimization appliance that accelerates application performance and reduces bandwidth usage.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	riverbed
product	steelconnect
service	/opt/hal/bin/hal, alarmd, crld, domaind, hald_model, link_control, lumberjack_rbt-upgrader, lumberjack_rbt, mdreq, mgmtd, ocd, periodic_raidcheck, pm, rcud, restd, rgpd, rscored-upgrader, rscored, rstild-upgrader, rstild, sched, statsd, wdt, webasd

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
riverbed:syslog	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: STEELHEAD.

9.34.2 - SteelHead

SteelHead: Software-defined WAN solution for centralized network management and secure cloud connectivity.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	riverbed
product	steelhead
service	sport

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
riverbed:steelhead	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: RIVERBED.

9.35 - RSA

9.35.1 - Authentication Manager

Authentication Manager: Manages two-factor authentication using RSA SecurID tokens for secure access to enterprise resources.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	rsa
product	authentication-manager
service	SecureAuth2

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
rsa:securid:admin:syslog	netauth
rsa:securid:system:syslog	netauth
rsa:securid:runtime:syslog	netauth
rsa:securid:syslog	netauth

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: RSA_AUTH_MANAGER.

9.36 - rsyslog

Axoflow treats rsyslog sources as a generic syslog source. To send data from rsyslog to Axoflow, just configure rsyslog to send data to an AxoRouter instance using the syslog protocol.

Note that even if rsyslog is acting as a relay (receiving data from other clients and forwarding them to AxoRouter), on the Topology page it will be displayed as a data source.

Prerequisites

You have administrative access to the device running rsyslog.
The date, time, and time zone are correctly set on the appliance.
You have an AxoRouter deployed and configured with a Syslog connector that has parsing and classification enabled (by default, every AxoRouter has such connectors). This device is going to receive the data from the source.
You know the IP address the AxoRouter. To find it:
1. Open the Axoflow Console.
2. Select the Routers or the Topology page.
3. Select on AxoRouter instance that is going to receive the logs.
4. Check the Networks > Address field.

9.37 - SecureAuth

9.37.1 - Identity Platform

Identity Platform: Delivers identity and access management with adaptive authentication and single sign-on capabilities.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	secureauth
product	idp

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
secureauth:idp	netops

Tested with: SecureAuth IdP Splunk App

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: SECUREAUTH_SSO.

9.38 - Skyhigh Security

9.38.1 - Secure Web Gateway

Secure Web Gateway: Inspects and filters web traffic to protect against malware, enforce policies, and prevent data loss.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	skyhigh
product	secure-web-gateway
service	mwg

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
mcafee:wg:leef	mcafee:wg	netproxy
mcafee:wg:kv	mcafee:wg	netproxy

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: MCAFEE_WEBPROXY.

Earlier name/vendor

McAfee Secure Web Gateway

9.39 - SonicWall

9.39.1 - SonicWall

SonicWall: Delivers firewall, VPN, and deep packet inspection to protect networks from cyber threats and intrusions.

The following sections show you how to configure SonicWall firewalls to send their log data to Axoflow.

CAUTION:

Prerequisites

You have administrative access to the firewall.
The date, time, and time zone are correctly set on the firewall.
You have an AxoRouter deployed and configured with a Syslog connector that has parsing and classification enabled (by default, every AxoRouter has such connectors). This device is going to receive the data from the firewall.
You know the IP address the AxoRouter. To find it:
1. Open the Axoflow Console.
2. Select the Routers or the Topology page.
3. Select on AxoRouter instance that is going to receive the logs.
4. Check the Networks > Address field.

Steps for SonicOS 7.x

Note: The steps involving the SonicWall user interface are just for your convenience, for details, see the official SonicWall documentation.

Log in to your SonicWall device. You need administrator privileges to perform the configuration.
Register the address of your AxoRouter as an Address Object.
1. Select MENU > OBJECT.
2. Select Match Objects > Addresses > Address objects.
3. Click Add Address.
4. Configure the following settings:
  - Name: Enter a name for the AxoRouter, for example, AxoRouter.
  - Zone Assignment: Select the correct zone.
  - Type: Select Host.
  - IP Address: Enter the IP address of your AxoRouter: %axorouter-ip%
5. Click Save.
Set your AxoRouter as a syslog server.
1. Navigate to Device > Log > Syslog.
2. Select the Syslog Servers tab.
3. Click Add.
4. Configure the following options:
  - Name or IP Address: Select the Address Object of AxoRouter.
  - Server Type: Select Syslog Server.
  - Syslog Format: Select Enhanced.
  If your Syslog server does not use default port 514, type the port number in the Port field.
  By default, AxoRouter accepts data on the following ports (unless you’ve modified the default connector rules):
  - 514 UDP and TCP for RFC3164 (BSD-syslog) and RFC5424 (IETF-syslog) formatted traffic. AxoRouter automatically recognizes and handles both formats.
  - 601 TCP for RFC5424 (IETF-syslog) and RFC3164 (BSD-syslog) formatted traffic. AxoRouter automatically recognizes and handles both formats.
  - 6514 TCP for TLS-encrypted syslog traffic.
  - 4317 TCP for OpenTelemetry log data.
  To receive data on other ports or other protocols, configure other connector rules for the AxoRouter host.
  
  For TLS-encrypted syslog connections, create a new connector rule or edit an existing one, and configure the keys and certificates needed to encrypt the connections. For details, see Syslog.
  
  Note Make sure to enable the ports you’re using on the firewall of your host.
Add the source to Axoflow Console.
1. Open the Axoflow Console and select Topology.
2. Select Create New Item > Source.
  - If the source is actively sending data to an AxoRouter instance, select Detected, then select your source.
  - Otherwise, select the vendor and product corresponding to your source from the Predefined sources, then enter the parameters of the source, like IP address and FQDN.
  Note During log tapping, you can add hosts that are actively sending data to an AxoRouter instance by clicking Register source.
3. (Optional) Add custom labels as needed.
4. Select Create.

Steps for SonicOS 6.x

Note: The steps involving the SonicWall user interface are just for your convenience, for details, see the official SonicWall documentation.

Log in to your SonicWall device. You need administrator privileges to perform the configuration.
Register the address of your AxoRouter as an Address Object.
1. Select MANAGE > Policies > Objects > Address Objects.
2. Click Add.
3. Configure the following settings:
  - Name: Enter a name for the AxoRouter, for example, AxoRouter.
  - Zone Assignment: Select the correct zone.
  - Type: Select Host.
  - IP Address: Enter the IP address of your AxoRouter: %axorouter-ip%
4. Click Add.
Set your AxoRouter as a syslog server.
1. Navigate to MANAGE > Log Settings > SYSLOG.
2. Click ADD.
3. Configure the following options:
  - Syslog ID: Enter an ID for the firewall. This ID will be used as the hostname in the log messages.
  - Name or IP Address: Select the Address Object of AxoRouter.
  - Server Type: Select Syslog Server.
  - Enable the Enhanced Syslog Fields Settings.
4. Click OK.
Add the source to Axoflow Console.
1. Open the Axoflow Console and select Topology.
2. Select Create New Item > Source.
  - If the source is actively sending data to an AxoRouter instance, select Detected, then select your source.
  - Otherwise, select the vendor and product corresponding to your source from the Predefined sources, then enter the parameters of the source, like IP address and FQDN.
  Note During log tapping, you can add hosts that are actively sending data to an AxoRouter instance by clicking Register source.
3. (Optional) Add custom labels as needed.
4. Select Create.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	dell
product	sonicwall

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
dell:sonicwall	netfw

Tested with: Dell SonicWall Add-on for Splunk technical add-on

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: SONIC_FIREWALL.

9.40 - Splunk

9.40.1 - Heavy Forwarder

Heavy Forwarder: Receive data from Splunk.

This page describes how to configure your Splunk Heavy Forwarders to send data to AxoRouter.

The Axoflow Forwarder app works beside an existing Splunk configuration by creating an axoflow server group which will not be part of the default group in the[tcpout] stanza. Messages will be cloned to the axoflow group separately during a transformation process.

Prerequisites

You’ll need to install the Axoflow Forwarder app on your Heavy Forwarders. Currently, you can request the app directly from Axoflow. Contact our support team for details.
You know the IP address the AxoRouter. To find it:
1. Open the Axoflow Console.
2. Select the Routers or the Topology page.
3. Select on AxoRouter instance that is going to receive the logs.
4. Check the Networks > Address field.

Steps

To configure your Splunk Heavy Forwarders to send data to AxoRouter. Complete the following steps.

Create a new Syslog Connector rule with the following parameters:
1. Select Routers > Create New Rule > Syslog > Custom
2. Enter splunk-hf into the Rule Name field.
3. Set the Router Selector so it matches the AxoRouter instances where your Splunk Heavy Forwarders will be forwarding their data. If you leave the Router Selector field empty, the rule will match all AxoRouters.
4. In the Preprocessing steps section, enable Classify.
5. In the Syslog settings section:
  1. Select the TCP protocol.
  2. Enter 9900 into the Port field.
6. Select Create.
Install the Axoflow Forwarder app you’ve received from the Axoflow Support Team on your Splunk Heavy Forwarders.
1. Configure name resolution for the axorouter host by completing one of the following:
  - Add axorouter to the /etc/hosts file to resolve to the IP address of your AxoRouter instance where this host is sending data.
  - Alternatively, you can add the following snippet to your /opt/splunk/etc/system/local/outputs.conf file:
```
[tcpout:axoflow]
server = <AXOROUTER_IP1>:9900, <AXOROUTER_IP2>:9900

# configure maxQueueSize to allow for a temporary in-memory buffer if the destination is slow or unavailable
# maxQueueSize = 100MB
# configure a persistentQueueSize to allow for data to be queued on disk if the destination is slow or unavailable
# persistentQueueSize = 1GB
```
    Note that if you set multiple AxoRouters in the server field, the forwarder will load-balance among them.
    
    Configure either in-memory (maxQueueSize) or on-disk (persistentQueueSize) queueing to avoid data loss in case the destination is slow or unavailable.
2. Install the Axoflow Forwarder app using the Splunk UI.
3. Restart splunkd.
Add the source to Axoflow Console.
1. Open the Axoflow Console and select Topology.
2. Select Create New Item > Source.
  - If the source is actively sending data to an AxoRouter instance, select Detected, then select your source.
  - Otherwise, select the vendor and product corresponding to your source from the Predefined sources, then enter the parameters of the source, like IP address and FQDN.
  Note During log tapping, you can add hosts that are actively sending data to an AxoRouter instance by clicking Register source.
3. (Optional) Add custom labels as needed.
4. Select Create.

9.41 - Superna

9.41.1 - Eyeglass

Eyeglass: Manages and automates data protection, DR, and reporting for PowerScale environments.

The following sections show you how to configure Superna Eyeglass to send their log data to Axoflow.

CAUTION:

Prerequisites

You have administrative access to Superna Eyeglass.
You have an AxoRouter deployed and configured with a webhook connector. This device is going to receive the data from Superna Eyeglass.
You know the IP address the AxoRouter. To find it:
1. Open the Axoflow Console.
2. Select the Routers or the Topology page.
3. Select on AxoRouter instance that is going to receive the logs.
4. Check the Networks > Address field.

Steps

Note: The steps involving the Superna Eyeglass user interface are just for your convenience, for details, see the official documentation.

Log in to Ransomware Defender and open the Zero Trust menu.
Click the plus sign to add a webhook target.
Set the parameters of the webhook.
- Name: Enter a name for the webhook, for example, Axoflow.
- URL: Enter the URL of the webhook connector of the AxoRouter instance where you want to post messages.
- Event Severity Filter: Select the severities of the events that you want to forward to the webhook.
- Lifecycle filter: Select the lifecycle changes that trigger a post message to the webhook.
Click Save, then the Test webhooks button. This will send a post message with a sample payload.
Add the source to Axoflow Console.
1. Open the Axoflow Console and select Topology.
2. Select Create New Item > Source.
  - If the source is actively sending data to an AxoRouter instance, select Detected, then select your source.
  - Otherwise, select the vendor and product corresponding to your source from the Predefined sources, then enter the parameters of the source, like IP address and FQDN.
  Note During log tapping, you can add hosts that are actively sending data to an AxoRouter instance by clicking Register source.
3. (Optional) Add custom labels as needed.
4. Select Create.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	superna
product	eyeglass

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
superna:eyeglass	main

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: SUPERNA_EYEGLASS.

9.42 - syslog-ng

By default, Axoflow treats syslog-ng sources as a generic syslog source.

The easiest way to send data from syslog-ng to Axoflow is to configure it to send data to an AxoRouter instance using the syslog protocol.
If you’re using syslog-ng Open Source Edition version 4.4 or newer, use the syslog-ng-otlp() driver to send data to AxoRouter using the OpenTelemetry Protocol.

Note that even if syslog-ng is acting as a relay (receiving data from other clients and forwarding them to AxoRouter), on the Topology page it will be displayed as a data source.

Prerequisites

You have administrative access to the device running syslog-ng.
The date, time, and time zone are correctly set on the appliance.
You have an AxoRouter deployed and configured with a Syslog connector that has parsing and classification enabled (by default, every AxoRouter has such connectors). This device is going to receive the data from the source.
You know the IP address the AxoRouter. To find it:
1. Open the Axoflow Console.
2. Select the Routers or the Topology page.
3. Select on AxoRouter instance that is going to receive the logs.
4. Check the Networks > Address field.

Note To receive more detailed metrics about the data processed by syslog-ng, consider onboarding the host into Axoflow and instrumenting its configuration.

9.43 - Thales

9.43.1 - Vormetric Data Security Platform

Vormetric Data Security Platform: Provides data encryption, key management, and access controls across cloud and on-premise environments.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	thales
product	vormetric
service	vee-FS
format	text-plain

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
thales:vormetric	netauth

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: VORMETRIC.

9.44 - Trellix

9.44.1 - Central Management System (CMS)

Central Management System (CMS): Centralized policy and configuration management platform for Trellix security products.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	trellix
product	cms
service	fenotify
format	cef

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
trellix:cms	trellix:cms	netops

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: FIREEYE_CMS.

9.44.2 - Email Threat Prevention (ETP)

Email Threat Prevention (ETP): Analyzes and filters email traffic to block phishing, malware, and targeted email-based threats.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	trellix
product	etp
format	cef

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
fe_etp	fireeye

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: FIREEYE_ETP.

9.44.3 - Endpoint Security (HX)

Endpoint Security (HX): Detects and responds to advanced threats on endpoints using behavior-based analysis and threat intel.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	trellix
product	hx
service	cef, fenotify
format	text-json \| cef

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
hx_json	fireeye
fe_json	fireeye
hx_cef_syslog	fireeye

Tested with: FireEye Add-on for Splunk Enterprise

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: FIREEYE_HX.

Earlier name/vendor

FireEye Endpoint Security (HX)

9.44.4 - ePolicy Orchestrator (EPO)

ePolicy Orchestrator (EPO): Analyzes and filters email traffic to block phishing, malware, and targeted email-based threats.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	trellix
product	epo

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index	source
mcafee:epo:syslog	epav	trellix_endpoint_security

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: MCAFEE_EPO.

Earlier name/vendor

McAfee ePolicy Ochestrator (EPO)

9.44.5 - MPS

MPS: Appliance for detecting and blocking advanced threats through inline malware inspection.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	trellix
product	mps
format	cef

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	source	index
trellix:mps	trellix:mps	netops

9.45 - Trend Micro

9.45.1 - Deep Security Agent

Deep Security Agent: Provides anti-malware, intrusion prevention, and log inspection for cloud and on-prem servers.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	trend-micro
product	deep-security-agent
format	cef

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
deepsecurity	epintel
deepsecurity-system_events	epintel
deepsecurity-intrusion_prevention	epintel
deepsecurity-firewall	epintel
deepsecurity-antimalware	epintel
deepsecurity-integrity_monitoring	epintel
deepsecurity-log_inspection	epintel
deepsecurity-web_reputation	epintel
deepsecurity-app_control	epintel
deepsecurity-system_events	epintel

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: TRENDMICRO_DEEP_SECURITY.

9.46 - Ubiquiti

9.46.1 - Unifi

Unifi: Manages network devices including routers, switches, and access points with centralized control.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	ubiquiti
product	unifi
service	crond, logread, kernel, mcad, switch, UDMPRO

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
ubnt	netops
ubnt:cef	netops
ubnt:dhcp	netops
ubnt:dnsmasq	netops
ubnt:edgeswitch	netops
ubnt:hostapd	netops
ubnt:link	netops
ubnt:mcad	netops
ubnt:sudo	netops
ubnt:wireless	netops
ubnt:fw	netfw
ubnt:fw:cef	netfw

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: UBIQUITI_SWITCH.

9.47 - Varonis

9.47.1 - DatAdvantage

DatAdvantage: Monitors data access and permissions to detect insider threats and automate compliance reporting.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	varonis
product	datadvantage
format	cef

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
varonis:ta	main

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: VARONIS.

9.48 - Vectra AI

Earlier name/vendor

Vectra Cognito

9.48.1 - X-Series

X-Series: Detects and investigates cyberattacks across cloud, data center, and enterprise networks using AI.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	vectra
product	x-series
service	vectra_cef, vectra_cef_account_detection, vectra_cef_audit
format	cef

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
vectra:cognito:detect	main
vectra:cognito:accountdetect	main
vectra:cognito:accountscoring	main
vectra:cognito:audit	main
vectra:cognito:campaigns	main
vectra:cognito:health	main
vectra:cognito:hostscoring	main
vectra:cognito:accountlockdown	main

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: VECTRA_DETECT.

9.49 - Zscaler appliances

9.49.1 - Zscaler Nanolog Streaming Service

Zscaler Nanolog Streaming Service: Cloud-based secure internet gateway that inspects traffic for threats and enforces policies.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	zscaler
product	nss
service	ZscalerNSS

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
zscalernss-alerts	netops
zscalernss-tunnel	netops
zscalernss-web	netproxy
zscalernss-web:leef	netproxy

Tested with: Zscaler Technical Add-On for Splunk

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: ZSCALER_INTERNET_ACCESS.

9.49.2 - Zscaler Log Streaming Service

Zscaler Log Streaming Service: Provides secure remote access to internal apps without exposing them to the public internet.

To onboard such a source to Axoflow, complete the generic appliance onboarding steps.

Labels

Axoflow automatically adds the following labels to data collected from this source:

label	value
vendor	zscaler
product	lss

Sending data to Splunk

When sending the data collected from this source to Splunk, Axoflow uses the following sourcetype and index settings:

sourcetype	index
zscalerlss-zpa-app	netproxy
zscalerlss-zpa-audit	netproxy
zscalerlss-zpa-auth	netproxy
zscalerlss-zpa-bba	netproxy
zscalerlss-zpa-connector	netproxy

Tested with: Zscaler Technical Add-On for Splunk

Sending data to Google SecOps

When sending the data collected from this source to a dynamic Google SecOps destination, Axoflow sets the following log type: ZSCALER_ZPA, ZSCALER_ZPA_AUDIT.

Sources

1 - Generic tips

Default connectors

Open ports

Prerequisites

Steps

2 - Edge collection rules

Create collection rule

Modify collection rule

Add edge host to existing collection rule

2.1 - File Collector

Add new File Collector

Related metrics

Advanced options

2.2 - Windows Event Log

Add new Event Log Collector

Related metrics

Advanced options

2.3 - Windows Event Tracing

Add new ETW Collector

Related metrics

Advanced options

3 - Data forwarding from edge hosts

Create data forwarding rule

Modify forwarding rule

Add edge host to existing forwarding rule

4 - AxoRouter connector rules

Create connector rule

Modify connector rule

Add AxoRouter to existing connector rule

5 - OpenTelemetry

Prerequisites

Add new OpenTelemetry connector

Labels

6 - Syslog

Prerequisites

Add new syslog connector

Protocol-specific connector options

Flow-control options

TCP options

TLS options

Labels

7 - Webhook

Prerequisites

Add new webhook connector

Metadata fields

8 - Windows Event Collector (WEC)

Prerequisites

Add new Windows Event Log connector

Additional options

Metadata fields

9 - Vendors

Prerequisites

Steps

9.1 - A10 Networks

9.1.1 - vThunder

Labels

Sending data to Splunk

Sending data to Google SecOps

9.2 - Amazon

9.2.1 - CloudWatch

Prerequisites

Steps

Labels

Sending data to Splunk

Sending data to Google SecOps

9.3 - Axoflow

9.3.1 - AxoSyslog

Labels

9.4 - Broadcom

9.4.1 - Edge Secure Web Gateway (Edge SWG)

Labels

Sending data to Splunk

Sending data to Google SecOps

Earlier name/vendor

9.4.2 - NSX

Labels

Sending data to Splunk

Sending data to Google SecOps

Earlier name/vendor