Available Commands in the Sensor CLI Access Window

Shows asset information.

Shows CM Controller IP address and connection status.

Shows information on Customer Log Parsers, if applied.

Shows MAC and IP address for sensor data port(s) (where data is ingested by the sensor).

Shows actions being taken to limit disk usage.

Shows the IP address of the sensor's DNS server.

Shows deep packet inspection information, including the categorization for different applications. Note that the output for this command can be lengthy. Use the all parameter to see all entries in paged output (for example, show dpi all).

Shows information on the number of packets dropped by the sensor broken out by Rx and Tx and interface.

Shows syn flood detection information.

Shows the IP address of the sensor's default gateway.

Shows equivalent output of the Linux ifconfig command with status, packets, drops, and bytes Rx and Tx broken out by interface.

Shows information on AFIX IPFIX classification engines.

Shows information on AFIX JSON metadata transfer.

Shows information on the configuration of and records sent by different log collectors.

Shows information on logs received and forwarded. Also indicates whether specific log forwarding features (such as the HTTP JSON Parser, forwarding to an external server, or TLS log forwarding) are enabled, as well as the number of workers provisioned for the sensor by the system. If you are using a custom log forwarder certificate with the TLS log forwarding feature, its name is displayed here, as well.

Shows the log level for different Stellar Cyber modules. Note that you can also set the log level for different modules from the CLI Access window using the set loglevel command; see the table below.

Shows detailed statistics on malware sandbox usage, including the total number of IDS events broken out by the number of events buffered by the sensor and the number already sent to the DP.

Note: The 5.3.0 sensor improves its approach to sending IDS events to the DP and sends them as soon as they are received, only buffering events when the sensor cannot reach the DP. Because of this, you may notice that the values reported in the Output buffering section of the show maltrace output for Buffered and Outputed are smaller than those reported in previous releases. That happens because the 5.3.0 sensor is not buffering as many events, sending them to the DP immediately, instead.

Shows information on control and data plane memory availability and usage.

Shows information on the black list of metadata applications (traffic explicitly excluded from ingestion/evaluation in the sensor profile).

Note that the output for this command can be lengthy. The following tips can help you see the entries that interest you:

• Use the all parameter to see all entries in paged output (for example, show metalist all).

• Use a regex filter to exclude aella_log_forwarder entries and see only user-defined applications. For example:

  show metalist regex ^(?!.*aella_log_forwarder).*

  show metalist all regex ^(?!.*aella_log_forwarder).*

Shows information on configured traffic mirroring.

Modular Sensors only. Shows which modular features are enabled on a modular sensor (for example, log collector, aggregator, Tenable scanner, and so on), as well as its current CPU, RAM, and disk provisioning.

Modular Sensors only. Shows the amount of CPU, RAM, and disk required to support different combinations of modular sensor features.

Lists the NICs installed in the sensor along with their names, driver names, driver versions, firmware versions, and bus information.

Lists the configured NTP servers for this sensor in order of use.

Shows packet processing settings, including slicing and deduplication.

Shows detailed information on internal AFIX process mapping, including NUMA register mapping.

Shows information on proxies configured for the sensor, if any.

Shows information on the configured data receiver.

Shows information on the AFIX ring.

Shows static route table entries.

Shows information on configured maltrace rules.

Shows detailed scan information on sensor.

Provides the service to AppID mapping for the sensor, including the NUMA register for each. Note that the output for this command can be lengthy. Use the all parameter to see all entries in paged output (for example, show service all).

Provides a session table for the sensor listing ongoing sessions and their NUMA mappings and summary statistics. You can filter this command by source/destination IP addresses and ports using the following syntax:

show session [source ip [port]] [dest ip [port]]

Shows the status of key Stellar Cyber services on the sensor.

Not supported.

Available if tenable nessus is enabled in the sensor profile. Shows status of the scanner.

Shows information on CPU threads.

Shows system time.

Shows top resource usage by process.

Shows report on upgrades for this sensor.

Shows information on user-defined applications for this sensor.

Note that the output for this command can be lengthy. The following tips can help you see the entries that interest you:

• Use the all parameter to see all entries in paged output (for example, show userapp all).

• Use a regex filter to exclude aella_log_forwarder entries and see only user-defined applications. For example:

  show userapp regex ^(?!.*aella_log_forwarder).*

  show userapp all regex ^(?!.*aella_log_forwarder).*

Shows the sensor software version, license status, features, platform, and basic configuration. Also provides detailed information on CPU and memory usage:

• Total, free, and used memory is reported based on the output of the free -m Linux command.

• CPU usage is reported based on the output of the top -n 1 Linux command.

• Total, available, and used 1K disk blocks are reported based on the output of the df command.

You can also use the output of the show version command to determine whether the sensor is operating in SaaS or on-prem/pre-SaaS mode:

• Sensors operating in on-prem/pre-SaaS mode include a p at the end of their AOS Version in the show version output. For example:

  AOS Version : 5.2.0_99e79ab-p

• Sensors operating in SaaS mode do not include the p in their AOS Version.

Shows interfaces available for use as a VXLAN tunnel destination.

Shows Information on VXLAN tunnel configuration.

Lets you set the IP address to reach the management interface of the Data Processor from the sensor or aggregator. For a DP cluster, this is the IP address of the DL-master's management interface. For a single DP deployment, this is simply the DP's management IP address. You can supply either an IP address or a hostname. Running this command from the Sensor CLI Access window can be useful when migrating sensors from one DP to another.

Note: Using this command from the Sensor CLI Access window disconnects the sensor from its current DP. Because of this, you need to manually close the Sensor CLI Access window once the disconnection occurs.

The syntax is as follows:

• cm_addr – the IP address or hostname of the managing DP.

• safe – reverts the CM address to the previous address if connection to the new one is not successful. This parameter is automatically used by Stellar Cyber when set cm is executed from the Sensor CLI Access window regardless of whether you included it in the command line.

• force – sets the CM address to whatever you specify, regardless of connection success. Be careful when using this option.

Stellar Cyber strongly recommends that you always use the safe argument with set cm in order to prevent yourself from accidentally orphaning a sensor by assigning an incorrect IP address.
As a safeguard, the safe option is used automatically when you run set cm from the Sensor CLI Access window.

Lets you set the log level for different modules. The syntax is as follows:

You can also set the loglevel timeout with the following command:

Stellar Cyber recommends that you only change the log level for modules while working with Custom Success personnel. If you do decide to change log levels, a good way to start is by checking the current log levels with the show log level command. The default log level for all modules is info.

The available modules (services) for which you can set the log level are as follows:

• audit (aella_audit)

• conf (aella_conf)

• ctrl (aella_ctrl)

• flow (aella_flow)

• mon (aella_mon)

The available log levels are as follows, from least to most severe:

• debug

• info

• warning

• error

• critical

As an example, you can set the log level for aella_flow to warning with the following command:

set loglevel flow warning

When you specify a log level, Stellar Cyber records events of the specified severity and above. So, for example, if you specify a log level of error, only events with a severity of error and critical are logged.

The log level setting also directly affects the quantity of events logged. For example, if you specify a log level of debug for a service, all events for that module are logged, regardless of severity.

Log Level Tips

Keep in mind the following tips when making changes to the log level:

• Stellar Cyber strongly recommends that you consult with Customer Success before changing log levels for a service.

• If you do make changes to the log level, Stellar Cyber recommends that you also set a loglevel timeout so that the log level returns to its normal state after whatever testing you are performing.

• Stellar Cyber recommends that you keep track of the time at which you change the log level. This can help the Customer Success team assist you with troubleshooting.

Lets you specify an NTP server for the sensor. The syntax is as follows:

Specifying an NTP server does not configure a time zone for the sensor. During installation, the timezone for a sensor is automatically set to UTC+0. Since the logs for some security products may only include the local time without a timezone, Stellar Cyber recommends that you set the sensor timezone to the same timezone as your security product. Set the time zone for a sensor from the Sensor List. Refer also to Best Practices for NTP and Timezones .

Lets you set IP configuration for a sensor interface by name, including its IP address, default gateway, and DNS server. Start by using show interface to get the name of the interface you want to configure. For example, to configure the management interface, you would use set interface management <arguments>.

The syntax is as follows:

• ip [<IP Address/Netmask> | dhcp]
• gateway <IP Address>
• dns <IP Address>