The following section gives you a generic overview on how to configure a source to send its log data to Axoflow. If there is a specific section for your source, follow that instead of the generic procedure. For details, see the documentation of your source.

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

By default, Axoflow Console has Connector rules that create the following connectors on AxoRouter deployments.

Parsing and classification is enabled for the default connectors. To create other connectors, or modify the default ones see 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 Hosts or the Topology page.
3. Click 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 - Connector rules

Connectors define the methods and entry points where AxoRouter receives data from the sources.

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, open the Connectors page 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.

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, 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 Connectors > 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.
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 with 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 match 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 Connectors 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 Hosts or Topology page, then select Connectors. 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.

3 - 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 Connectors > 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.
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 with 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

4 - 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 Connectors > 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.
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 with 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. 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).

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

5 - 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 Connectors > 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.
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 with 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`

6 - 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 Connectors > 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.
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 with 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. Set the Hostname field. The clients will address this hostname. Note that:
  - The Common Name of the server’s certificate (set in the following steps) must contain this hostname, otherwise the clients will reject the connection.
  - You’ll have to use this hostname when configuring the Subscription Manager address in the Group Policy Editor.
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.
  - Server private key path: The private key of the server certificate.
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.
```
<Query Id="0">
    <Select Path="Application">*</Select>
    <Select Path="Security">*</Select>
    <Select Path="Setup">*</Select>
    <Select Path="System">*</Select>
</Query>
```
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>`

7 - 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 Hosts or the Topology page.
3. Click 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.

7.1 - A10 Networks

7.1.1 - vThunder

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

To onboard such an appliance 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.

7.2 - Amazon

7.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 Hosts or the Topology page.
3. Click 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 Hosts > 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.

7.3 - Broadcom

7.3.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 an appliance 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

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

7.3.2 - NSX

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

To onboard such an appliance 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

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

7.4 - Check Point

7.4.1 - Anti-Bot

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

To onboard such an appliance 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.

7.4.2 - Anti-Malware

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

To onboard such an appliance 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.

7.4.3 - Anti-Phishing

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

To onboard such an appliance 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.

7.4.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 an appliance 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.

7.4.5 - CPMI Client

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

To onboard such an appliance 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.

7.4.6 - cpmidu_update_tool

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

To onboard such an appliance 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.

7.4.7 - Database Tool

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

To onboard such an appliance 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

7.4.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 an appliance 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.

7.4.9 - Endpoint Compliance

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

To onboard such an appliance 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.

7.4.10 - Endpoint Management

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

To onboard such an appliance 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

7.4.11 - Forensics

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

To onboard such an appliance 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.

7.4.12 - GO Password Reset

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

To onboard such an appliance 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.

7.4.13 - HTTPS Inspection

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

To onboard such an appliance 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

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.

7.4.14 - IPS

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

To onboard such an appliance 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.

7.4.15 - MDS Query Tool

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

To onboard such an appliance 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

7.4.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 an appliance 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.

7.4.17 - Mobile Access

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

To onboard such an appliance 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

7.4.18 - Next-Generation Firewall (NGFW)

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

To onboard such an appliance 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

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.

7.4.19 - QoS

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

To onboard such an appliance 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.

7.4.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.

7.4.21 - Query Database

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

To onboard such an appliance 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

7.4.22 - SmartConsole

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

To onboard such an appliance 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

7.4.23 - SmartUpdate

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

To onboard such an appliance 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

7.4.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 an appliance 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.

7.4.25 - URL Filtering

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

To onboard such an appliance 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

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.

7.4.26 - Web API

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

To onboard such an appliance 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

7.5 - Cisco

7.5.1 - Access Control System (ACS)

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

To onboard such an appliance 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

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.

7.5.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 an appliance 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.

7.5.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 an appliance 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.

7.5.4 - Cisco IOS

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

To onboard such an appliance 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.

7.5.5 - Digital Network Architecture (DNA)

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

To onboard such an appliance 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
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.

7.5.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 an appliance 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
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.

7.5.7 - Firepower

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

To onboard such an appliance 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
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.

7.5.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 an appliance 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

7.5.9 - Firewall Services Module (FWSM)

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

To onboard such an appliance 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.

7.5.10 - HyperFlex (HX, UCSH)

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

To onboard such an appliance 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
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.

7.5.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 an appliance 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

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.

7.5.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 an appliance 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

7.5.13 - IOS XR

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

To onboard such an appliance 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
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

7.5.14 - Meraki MX

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

To onboard such an appliance 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.

7.5.15 - Private Internet eXchange (PIX)

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

To onboard such an appliance 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.

7.5.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 an appliance 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
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

7.5.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 an appliance 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.

7.5.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 an appliance 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.

7.5.19 - Viptela

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

To onboard such an appliance 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
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.

7.6 - Citrix

7.6.1 - Netscaler

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

To onboard such an appliance 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
format	text-plain
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
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.

7.7 - Corelight

7.7.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 an appliance 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.

7.8 - CyberArk

7.8.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 an appliance 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.

7.8.2 - Vault

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

To onboard such an appliance 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.

7.9 - F5 Networks

7.9.1 - BIG-IP

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

To onboard such an appliance 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
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.

7.10 - FireEye

7.11 - Forcepoint

7.11.1 - Email Security

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

To onboard such an appliance 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

7.11.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 an appliance 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

7.11.3 - WebProtect

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

To onboard such an appliance 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

7.12 - Fortinet

7.12.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 Hosts or the Topology page.
3. Click 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
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.

7.12.2 - FortiMail

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

To onboard such an appliance 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
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.

7.12.3 - FortiWeb

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

To onboard such an appliance 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
product	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.

7.13 - Fortra

7.13.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 an appliance 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

7.14 - General Unix/Linux host

7.14.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 an appliance 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.name	dnsmasq, sshd

Sending data to Splunk

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

sourcetype	index
nix:syslog	netdns
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: NIX_SYSTEM.

7.15 - Imperva

7.15.1 - Incapsula

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

To onboard such an appliance 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.

7.15.2 - SecureSphere

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

To onboard such an appliance 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.

7.16 - Infoblox

7.16.1 - NIOS

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

To onboard such an appliance 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
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.

7.17 - Internet Systems Consortium (ISC)

7.17.1 - DHCPd

DHCPd:

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

Labels

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

label	value
vendor	isc
product	dhcpd

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
isc:dhcpd	netipam	program:dhcpd

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: ISC_DHCP.

7.18 - Ivanti

7.18.1 - Connect secure

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

To onboard such an appliance 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

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

7.19 - Juniper

7.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 an appliance 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
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.

7.20 - Kaspersky

7.20.1 - Endpoint Security

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

To onboard such an appliance 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
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.

7.21 - MicroFocus

7.22 - Microsoft

7.22.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 Hosts or the Topology page.
3. Click 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 Hosts > 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
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.

7.22.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 an appliance 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.

7.22.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.

7.23 - MikroTik

7.23.1 - RouterOS

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

To onboard such an appliance 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
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.

7.24 - NetFlow Logic

7.24.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 Hosts or the Topology page.
3. Click 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

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

7.25 - Netgate

7.25.1 - pfSense

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

To onboard such an appliance 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
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.

7.26 - Netmotion

7.26.1 - Netmotion

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

To onboard such an appliance 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
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.

7.27 - NETSCOUT

7.27.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 an appliance 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.

7.27.2 - Arbor Pravail (APS)

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

To onboard such an appliance 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

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)

7.28 - OpenText

7.28.1 - ArcSight

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

To onboard such an appliance 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

7.28.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 an appliance 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

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

7.29 - Palo Alto Networks

7.29.1 - Cortex XSOAR

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

To onboard such an appliance 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)

7.29.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 Hosts or the Topology page.
3. Click 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.

7.30 - Ping Identity

7.30.1 - PingAccess

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

To onboard such an appliance 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

7.31 - Powertech

7.32 - Progress

7.32.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 an appliance 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

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

7.33 - Riverbed

7.33.1 - SteelConnect

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

To onboard such an appliance 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

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.

7.33.2 - SteelHead

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

To onboard such an appliance 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

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.

7.34 - RSA

7.34.1 - Authentication Manager

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

To onboard such an appliance 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

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.

7.35 - 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 Hosts or the Topology page.
3. Click on AxoRouter instance that is going to receive the logs.
4. Check the Networks > Address field.

7.36 - SecureAuth

7.36.1 - Identity Platform

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

To onboard such an appliance 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.

7.37 - Skyhigh Security

7.37.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 an appliance 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

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

7.38 - SonicWall

7.38.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 Hosts or the Topology page.
3. Click 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.

7.39 - Superna

7.39.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 Hosts or the Topology page.
3. Click 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.

7.40 - 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 Hosts or the Topology page.
3. Click 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.

7.41 - Thales

7.41.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 an appliance 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
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.

7.42 - Trellix

7.42.1 - Central Management System (CMS)

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

To onboard such an appliance 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
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.

7.42.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 an appliance 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.

7.42.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 an appliance 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
format	text-json
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
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)

7.42.4 - ePolicy Orchestrator (EPO)

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

To onboard such an appliance 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)

7.42.5 - MPS

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

To onboard such an appliance 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

7.43 - Trend Micro

7.43.1 - Deep Security Agent

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

To onboard such an appliance 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.

7.44 - Ubiquiti

7.44.1 - Unifi

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

To onboard such an appliance 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

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.

7.45 - Varonis

7.45.1 - DatAdvantage

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

To onboard such an appliance 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.

7.46 - Vectra AI

Earlier name/vendor

Vectra Cognito

7.46.1 - X-Series

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

To onboard such an appliance 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
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.

7.47 - Zscaler appliances

7.47.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 an appliance 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

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.

7.47.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 an appliance 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.