Logo

A powerful, easily deployable network traffic analysis tool suite for network security monitoring

Quick Start

Documentation

Components

Supported Protocols

Configuring

Arkime

Dashboards

Hedgehog Linux

Contribution Guide

End-to-end Malcolm and Hedgehog Linux ISO Installation

This document outlines how to install Malcolm and Hedgehog Linux using the project’s installer ISOs. These instructions apply to installing this software both on a “bare metal” system or in a virtual machine environment using VMware, VirtualBox, QEMU/KVM, etc.

The Malcolm and Hedgehog Linux installers as described in these instructions are intended to be used to replace the existing operating system (if any) of the respective systems onto which they are installed; and, as such, are designed to require as little user input as possible. For this reason, there are NO user prompts or confirmations about partitioning and reformatting hard disks for use by the operating system. The installer assumes that all non-removable storage media (eg., SSD, HDD, NVMe, etc.) are available for use and ⛔🆘😭💀 will partition and format them without warning 💀😭🆘⛔.

In contrast to using the ISO installer, Malcolm can also be installed on any x86-64 (also known as x64, x86_64, AMD64, and Intel 64) or AArch64 (also known as ARM64) platform capable of running Docker or Podman. See the installation example using Ubuntu 22.04 LTS for that method of installation and configuration, or Windows host system configuration and macOS host system configuration for those platforms.

Table of Contents

Obtaining the Installation ISOs

Please see Downloading Malcolm for instructions on how to obtain the Malcolm and Hedgehog Linux installation ISOs.

As an alternative to the official release ISOs, instructions are provided for building the Malcolm installer ISO and Hedgehog Linux installer ISO (Malcolm’s dedicated network sensor appliance OS) from scratch.

“Burning” the Installation ISOs to USB Flash Drive

Various methods can be used to write the contents of an installer ISO image to a USB flash drive. One simple free and open-source application for doing so is Etcher, which can be used on Windows, macOS, and Linux platforms.

Alternatively, instructions specific to a particular operating system may be found online (e.g., Arch Linux, Debian Linux, Ubuntu Linux).

Using one of these methods, write the Malcolm and Hedgehog Linux installer ISOs to two 8GB or larger USB flash drives, respectively.

Alternatively, the ISO images could be burned to writable optical media (e.g., DVD±R). The Malcolm installer will likely need to be written to DVD±R DL (“dual layer” or “double layer”) media as the image exceeds the 4.7 GB storage provided by standard DVDs.

Etcher on macOS

Using Etcher on macOS

dd on Linux

Using dd on Linux

Booting the Installation Media

The ISO installers are compatible with systems that support EFI-mode and legacy (BIOS) booting. The procedure for configuring a system’s firmware to allow booting from USB or optical media varies from manufacturer to manufacturer. Manufacturers typically provide a “one-time boot” menu upon a specific keypress (e.g., F12 for Dell, F9 for HP, etc.). If needed, consult the documentation provided by the hardware manufacturer on how to access the boot options menu and boot from the newly-burned USB flash media or DVD±R.

EFI Boot Manager

An example of an EFI boot manager in QEMU

BIOS Boot Manager

An example of a BIOS boot options menu in QEMU

Malcolm Installation and Configuration

ISO Installation

Upon Booting the Malcolm installation ISO, users are presented with the following Boot menu. Use the arrow keys to select Install Malcolm, and press Enter.

The first screen of the installer

The next screen of the installer presents the following options relevant to installation:

The Install Malcolm menu

After users select the type of Malcolm install to perform, the installer will ask for several pieces of information prior to installing the Malcolm base operating system:

Example of the installer's password prompt

After the passwords have been entered, the installer will proceed to format the system drive and install Malcolm.

Installer progress

At the end of the installation process, users will be prompted with a few self-explanatory yes/no questions:

Following these prompts, the installer will reboot and the Malcolm base operating system will boot.

The Malcolm installer does not require an Internet connection to complete successfully. If the installer prompts users to configure network connectivity, they may choose “do not configure the network at this time.”

Desktop Environment

The Malcolm base operating system is a hardened Linux installation based on the current stable release of Debian running the XFCE desktop environment. The system has been preloaded with all of the components that make up Malcolm.

NetworkManager can be used to configure networking for Malcolm. NetworkManager can be configured by clicking the 🖧 (networked computers) icon in the system tray in the upper-right, or right-clicking the icon and selecting Edit Connections… to modify the properties of a given connection.

Display resolution should be detected and adjusted automatically. To make changes to display properties, click the Applications menu and select Settings → Display.

The panel bordering the top of the Malcolm desktop is home to a number of useful shortcuts:

Malcolm Desktop

Configuration

The first time the Malcolm base operating system boots the Malcolm Configuration wizard will start automatically. This same configuration script can be run again later by running ./scripts/configure from the Malcolm installation directory, or clicking the Configure Malcolm 🔳 icon in the top panel.

Malcolm Configuration on first boot

The configuration and tuning wizard’s questions proceed as follows. Users may not see every question listed in the bulleted list below as some questions depend on earlier responses. Usually the default selection is recommended unless otherwise indicated. The configuration values resulting from these questions (in bold) are stored in environment variable files in the ./config directory.

Configure Hostname and Time Sync

If users wish to change Malcolm’s hostname or configure system time synchronization, they can open a terminal (the icon immediately to the right of the Applications menu icon at the top of the Malcolm desktop) and run sudo configure-interfaces.py then enter the password. If users get an error about not belonging to the sudo group, run su -c configure-interfaces.py and use the root password instead.

Here users can configure Malcolm to keep its time synchronized with either an NTP server (using the NTP protocol), another Malcolm aggregator or another HTTP/HTTPS server. On the next dialog, choose the time synchronization method to configure.

Time synchronization method

If htpdate is selected, users will be prompted to enter the URL of an HTTP/HTTPS server (for another Malcolm instance, either port 443 or port 9200 over https may be used) and the time synchronization check frequency in minutes. A test connection will be made to determine if the time can be retrieved from the server.

*htpdate* configuration

If ntpdate is selected, users will be prompted to enter the IP address or hostname of the NTP server.

NTP configuration

Upon configuring time synchronization, a “Time synchronization configured successfully!” message will be displayed, after which users will be returned to the welcome screen. Select Cancel.

Setting up Authentication

Once the configuration questions have been completed as described above, users can click the circular yellow Malcolm icon the panel at the top of the desktop to start Malcolm. As authentication has not yet been configured, users will be prompted to do so. This authentication setup can be run again later by running ./scripts/auth_setup from the Malcolm installation directory.

Setting up authentication on Malcolm's first run

The Configure Authentication dialog

As this is the first time setting up authentication, ensure the all option is selected and press OK.

Users will be prompted to do the following:

Hedgehog Linux Installation and Configuration

More detailed instructions for configuring Hedgehog Linux can be found in that section of the documentation.

Hedgehog Linux ISO Installation

The Hedgehog Linux installation ISO follows the same process as the Malcolm installation above.

The installer will ask for a few pieces of information prior to installing Hedgehog Linux:

At the end of the installation process, users will be prompted with a few self-explanatory yes/no questions:

Following these prompts, the installer will reboot and Hedgehog Linux will boot into kiosk mode.

Kiosk mode can be exited by connecting an external USB keyboard and pressing Alt+F4, upon which the sensor user’s desktop is shown.

Desktop Environment

The Hedgehog Linux base operating system is a hardened Linux installation based on the current stable release of Debian running the XFCE desktop environment.

Display resolution should be detected and adjusted automatically. To make changes to display properties, click the Applications menu and select Settings → Display.

The panel bordering the top of the Malcolm desktop is home to a number of useful shortcuts:

Hedgehog Linux desktop

The Hedgehog Linux desktop

Configure Hostname, Interfaces and Time Sync

The first step of sensor configuration is to configure the network interfaces and sensor hostname. Clicking the Configure Interfaces and Hostname toolbar icon (or running configure-interfaces at a command line prompt) will prompt for the root password created during installation, after which the configuration welcome screen is shown. Select Continue to proceed.

Users may next select whether to configure the network interfaces, hostname, or time synchronization.

Selection to configure network interfaces, hostname, or time synchronization

Selecting Hostname, users will be presented with a summary of the current sensor identification information, after which a new sensor hostname may be specified. This name will be used to tag all events forwarded from this sensor in the events’ host.name field.

Specifying a new sensor hostname

Returning to the configuration mode selection, choose Interface. Users will be asked if they would like help identifying network interfaces. If they select Yes, users will be prompted to select a network interface, after which that interface’s link LED will blink for 10 seconds to identify itself. This network interface identification aid will continue to prompt users to identify further network interfaces until they select No.

Users will be presented with a list of interfaces to configure as the sensor management interface. This is the interface the sensor itself will use to communicate with the network in order to, for example, forward captured logs to an aggregate server. In order to do so, the management interface must be assigned an IP address. This is generally not the interface used for capturing data. Select the interface to which to assign an IP address. The interfaces are listed by name and MAC address and the associated link speed is also displayed if it can be determined. For interfaces without a connected network cable, generally a -1 will be displayed instead of the interface speed.

Management interface selection

Depending on their network configuration, users may now specify how the management interface will be assigned an IP address. In order to communicate with an event aggregator over the management interface, either static or dhcp must be selected.

Interface address source

If users select static, they will be prompted to enter the IP address, netmask, and gateway to assign to the management interface.

Static IP configuration

In either case, upon selecting OK the network interface will be brought down, configured, brought back up, and the result of the operation will be displayed. Users may choose Quit upon returning to the configuration tool’s welcome screen.

Returning to the configuration mode selection, choose Time Sync. Here users can configure the sensor to keep its time synchronized with an NTP server (using the NTP protocol), a local Malcolm aggregator, or another HTTP/HTTPS server. On the next dialog, choose the time synchronization method to configure.

Time synchronization method

If htpdate is selected, users will be prompted to enter the URL of an HTTP/HTTPS server (for another Malcolm instance, either port 443 or port 9200 over https may be used) and the time synchronization check frequency in minutes. A test connection will be made to determine if the time can be retrieved from the server.

*htpdate* configuration

If ntpdate is selected, users will be prompted to enter the IP address or hostname of the NTP server.

NTP configuration

Upon configuring time synchronization, a “Time synchronization configured successfully!” message will be displayed, after which users will be returned to the welcome screen. Select Cancel.

Configure Capture

Clicking the Configure Capture and Forwarding toolbar icon (or running configure-capture at the command line prompt) will launch the configuration tool for capture and forwarding. The root password is not required as it was for the interface and hostname configuration, as sensor services are run under the non-privileged sensor account. Select Continue to proceed. Users may select from a list of configuration options.

Select configuration mode

Capture

Choose Configure Capture to configure parameters related to traffic capture and local analysis. Users will be asked if they would like help identifying network interfaces. If they select Yes, users will be prompted to select a network interface, after which that interface’s link LED will blink for 10 seconds to identify itself. This network interface identification aid will continue to prompt users to identify further network interfaces until they select No.

Users will be presented with a list of network interfaces and prompted to select one or more capture interfaces. An interface used to capture traffic is generally a different interface than the one selected previously as the management interface, and each capture interface should be connected to a network tap or span port for traffic monitoring. Capture interfaces are usually not assigned an IP address as they are only used to passively “listen” to the traffic on the wire. The interfaces are listed by name and MAC address and the associated link speed is also displayed if it can be determined. For interfaces without a connected network cable, generally a -1 will be displayed instead of the interface speed.

Select capture interfaces

Upon choosing the capture interfaces and selecting OK, users may optionally provide a capture filter. This filter will be used to limit what traffic the PCAP service (netsniff-ng or tcpdump) and the traffic analysis services (zeek and suricata) will see. Capture filters are specified using Berkeley Packet Filter (BPF) syntax. For example, to indicate Hedgehog should ignore the ports it uses to communicate with Malcolm, users could specify not port 5044 and not port 5045 and not port 8005 and not port 8006 and not port 9200. Clicking OK will attempt to validate the capture filter, if specified, and will present a warning if the filter is invalid.

Specify capture filters

Next users must specify the paths where captured PCAP files and logs will be stored locally on the sensor. If the installation worked as expected, these paths should be prepopulated to reflect paths on the volumes formatted at install time for the purpose storing these artifacts. Usually these paths will exist on separate storage volumes. Enabling the PCAP and log pruning autostart services (see the section on autostart services below) will enable monitoring of these paths to ensure that their contents do not consume more than 90% of their respective volumes’ space. Choose OK to continue.

Specify capture paths

File extraction and scanning

Hedgehog Linux can leverage Zeek’s knowledge of network protocols to automatically detect file transfers and extract those files from network traffic as Zeek sees them.

To specify which files should be extracted, specify the Zeek file carving mode:

Zeek file carving mode

If unsure what mode to choose, both mapped (except common plain text files) (to carve and scan almost all files) and interesting (to only carve and scan files with mime types of common attack vectors) are probably good choices.

Next, specify which carved files to preserve (saved on the sensor under /capture/zeek/capture/extract_files/quarantine by default). In order to not consume all the sensor’s available storage space, the oldest preserved files will be pruned along with the oldest Zeek logs as described below with AUTOSTART_PRUNE_ZEEK in the autostart services section.

File quarantine

Users will prompted to specify which engine(s) to use to analyze extracted files. Extracted files can be examined through any of three methods:

File scanners

Files flagged as potentially malicious will be logged as Zeek signatures.log entries, and can be viewed in the Signatures dashboard in OpenSearch Dashboards when forwarded to Malcolm.

Hedgehog Linux provides an extracted files directory listing to browse and download Zeek-extracted files. As this interface is primarily intended to be accessed through the Malcolm user interface, this service is accessible only by IP addresses included in the ACL for artifact reachback from Malcolm over port 8006/tcp. The next two questions indicate whether or not Zeek-extracted files downloaded through this interface will be archived using the ZIP file format and what encryption password should be used, if any (either the ZIP archive file password or as the encryption key for AES-256-CBC-encrypted files if not using ZIP). Please read the Malcolm documentation for Automatic file extraction and scanning - User interface for more information on how to access preserved files.

Extracted file server configuration

Finally, users will be presented with the list of configuration variables that will be used for capture, including the values which have been selected up to this point in this section. Upon choosing OK these values will be written back out to the sensor configuration file located at /opt/sensor/sensor_ctl/control_vars.conf. Editing this file manually should be done with care. After confirming these values, users will be presented with a confirmation that these settings have been written to the configuration file then returned to the welcome screen.

Configure Forwarding

Select Configure Forwarding to set up forwarding logs and statistics from the sensor to an aggregator server, such as Malcolm.

Configure forwarders

There are three forwarder services used on the sensor, each for forwarding a different type of log or sensor metric.

arkime-capture: Arkime session forwarding

arkime-capture is not only used to capture PCAP files, but also to parse raw traffic into sessions and forward this session metadata to an OpenSearch database so it can be viewed in Arkime viewer, whether standalone or as part of a Malcolm instance. If using Hedgehog Linux with Malcolm, please read Correlating Zeek logs and Arkime sessions in the Malcolm documentation for more information.

First, select the OpenSearch connection transport protocol, either HTTPS or HTTP. If the metrics are being forwarded to Malcolm, select HTTPS to encrypt messages from the sensor to the aggregator using TLS v1.2 using ECDHE-RSA-AES128-GCM-SHA256. If HTTPS is chosen, users must choose whether to enable SSL certificate verification. When using a self-signed certificate (such as the one automatically created during Malcolm’s configuration), choose None.

OpenSearch connection protocol OpenSearch SSL verification

Next, enter the OpenSearch host IP address (ie., the IP address of the aggregator) and port. These metrics are written to an OpenSearch database using a RESTful API, usually using port 9200. Depending on network configuration, users may need to open a firewall port to allow this connection from the sensor to the aggregator.

OpenSearch host and port

Users will be asked to enter authentication credentials for the sensor’s connections to the aggregator’s OpenSearch API. After entering the username and the password, the sensor will attempt a test connection to OpenSearch using the connection information provided. If the Malcolm services have not yet been started, users may receive a Connection refused error. Select Ignore Error for the credentials to be accepted anyway.

OpenSearch username OpenSearch password Successful OpenSearch connection

Users will be asked to provide a “password hash secret” for the Arkime viewer cluster. This value corresponds to the passwordSecret value in Arkime’s config.ini file. Arkime uses this value to secure communication (specifically, the connection used when Arkime viewer retrieves a PCAP payload for display in its user interface) between Arkime viewers in instances of Malcolm and Hedgehog Linux. In other words, this value needs to be the same for the Malcolm instance and all of the instances of Hedgehog Linux forwarding Arkime sessions to that Malcolm instance. The corresponding value is set when setting up authentication during the Malcolm configuration.

Arkime supports compression for the PCAP files it creates. Select none (at the cost of requiring more storage for PCAP files saved on the sensor) or zstd (at the cost of higher CPU load when writing and reading PCAP files). If zstd is chosen, users will also be prompted for the compression level (something like 3 is probably a good choice).

PCAP compression

Finally, users be given the opportunity to review the Arkime capture options specified. Selecting OK will cause the parameters to be saved and will return to the configuration tool’s welcome screen.

capture settings confirmation

ssl-client-receive: Receive client SSL files for filebeat from Malcolm

As described above in the Malcolm configuration under Setting up Authentication, in order for a Hedgehog Linux to securely communicate with Malcolm, it needs the client certificates generated when users answered Y to “(Re)generate self-signed certificates for a remote log forwarder” during that setup. Malcolm can facilitate the secure transfer of these to a sensor running Hedgehog.

ssl-client-receive

Select ssl-client-receive on Hedgehog

Select ssl-client-receive from the Configuration Mode options on the Hedgehog, then press OK when prompted “Run auth_setup on Malcolm ‘Transfer self-signed client certificates…’.” Return to the Malcolm instance where auth_setup is running (or re-run it if needed) and press OK. Users will see a message with the title ssl-client-transmit that looks like this:

ssl-client-transmit

Run auth_setup and select ssl-client-transmit on Malcolm

Note Malcolm’s IP address (192.168.122.5 in the screenshot above) and the single-use code phrase (8736-janet-kilo-tonight in the screenshot above) and enter them on the Hedgehog:

ssl-client-receive-code

Enter Malcolm IP address and single-use code phrase on Hedgehog

After a few seconds (hopefully) a progress bar will update and show the files have been 100% transfered. They are automatically saved into the /opt/sensor/sensor_ctl/logstash-client-certificates directory on the sensor.

Press OK on the Malcolm instance. If Malcolm’s auth_setup process was being during Malcolm’s first run, Malcolm will continue to start up.

filebeat: Zeek and Suricata log forwarding

Filebeat is used to forward Zeek and Suricata logs to a remote Logstash instance for further enrichment prior to insertion into an OpenSearch database.

To configure filebeat, first provide the log path (the same path previously configured for log file generation).

Configure filebeat for log forwarding

Users must also provide the IP address of the Logstash instance to which the logs are to be forwarded, and the port on which Logstash is listening. These logs are forwarded using the Beats protocol, generally over port 5044. Depending on network configuration, users may need to open a firewall port to allow this connection from the sensor to the aggregator.

Configure filebeat for log forwarding

Users may specify a NetBox site to associate with the network traffic metadata forwarded to Malcolm by this sensor. See Asset Interaction Analysis for more information about NetBox.

NetBox site

Next users will be asked whether the connection used for log forwarding should be done unencrypted or over SSL. Unencrypted communication requires less processing overhead and is simpler to configure, but the contents of the logs may be visible to anyone able to intercept that traffic.

Filebeat SSL certificate verification

If SSL is chosen, users must choose whether to enable SSL certificate verification. If using a self-signed certificate (such as the one automatically created during Malcolm’s configuration, choose None.

Unencrypted vs. SSL encryption for log forwarding

The final step for SSL-encrypted log forwarding is to specify the SSL certificate authority, certificate, and key files. These files must match those used by the Logstash instance receiving the logs on the aggregator. The steps above under ssl-client-receive: Receive client SSL files for filebeat from Malcolm should have taken care of the transfer of these files between Malcolm and Hedgehog. Otherwise, manually copy (“sneakernet”) the files from the filebeat/certs/ subdirectory of the Malcolm installation to /opt/sensor/sensor_ctl/logstash-client-certificates on Hedgehog.

SSL certificate files

Once all the filebeat parameters are specified, users will be presented with a summary of the settings related to the forwarding of these logs. Selecting OK will cause the parameters to be written to filebeat’s configuration keystore under /opt/sensor/sensor_ctl/logstash-client-certificates and users will be returned to the configuration tool’s welcome screen. If the Malcolm services have not yet been started, users may receive a could not connect error. Select Ignore Error for the settings to be accepted anyway.

Confirm filebeat settings

miscbeat: System metrics forwarding

The sensor uses Fluent Bit to gather miscellaneous system resource metrics (CPU, network I/O, disk I/O, memory utilization, temperature, etc.) and the Beats protocol to forward these metrics to a remote Logstash instance for further enrichment prior to insertion into an OpenSearch database. Metrics categories can be enabled/disabled as described in the autostart services section of this document.

This forwarder’s configuration is almost identical to that of filebeat in the previous section. Select miscbeat from the forwarding configuration mode options and follow the same steps outlined above to set up this forwarder.

acl-configure: Configure ACL for artifact reachback from Malcolm

Users will be shown a dialog for a list of IP addresses used to populate a firewall access control list (ACL) for hosts allowed to connect back to the sensor for retrieving session payloads from its PCAP files (over port 8005/tcp) for display in Arkime viewer and for downloading files (over port 8006/tcp) extracted and preserved by Zeek. The list will be prepopulated with the IP address entered a few screens prior to this one.

PCAP retrieval ACL

tags-configure: Specify extra tags for forwarded logs

Users may populate a list of values, one per line, to be added to the tags field for logs forwarded from the sensor to a Malcolm aggregator. These tags may make it easier to identify or search for data during analysis.

Extra tags

Autostart services

Once the forwarders have been configured, the final step is to Configure Autostart Services. Choose this option from the configuration mode menu after the welcome screen of the sensor configuration tool.

Despite configuring capture and/or forwarder services as described in previous sections, only services enabled in the autostart configuration will run when the sensor starts up. The available autostart processes are as follows (recommended services are in bold text):

Note that only one packet capture engine (capture, netsniff-ng, or tcpdump) can be used.

Autostart services

Once autostart services are selected, users will be prompted to confirm the selections. Doing so will cause these values to be written back out to the /opt/sensor/sensor_ctl/control_vars.conf configuration file.

Autostart services confirmation

Once sensor configuration is complete, users should reboot Hedgehog to ensure all new settings take effect. If rebooting is not an option, click the Restart Sensor Services menu icon in the top menu bar, or open a terminal and run:

/opt/sensor/sensor_ctl/shutdown && sleep 10 && /opt/sensor/sensor_ctl/supervisor.sh

This will cause the sensor services controller to stop, wait a few seconds, and restart. Users may check the status of the sensor’s processes by choosing Sensor Status from the sensor’s kiosk mode, clicking the Sensor Service Status toolbar icon, or running /opt/sensor/sensor_ctl/status from the command line:

$ /opt/sensor/sensor_ctl/status 
arkime:arkime-capture            RUNNING   pid 6455, uptime 0:03:17
arkime:arkime-viewer             RUNNING   pid 6456, uptime 0:03:17
beats:filebeat                   RUNNING   pid 6457, uptime 0:03:17
beats:miscbeat                   RUNNING   pid 6458, uptime 0:03:17
clamav:clamav-service            RUNNING   pid 6459, uptime 0:03:17
clamav:clamav-updates            RUNNING   pid 6461, uptime 0:03:17
fluentbit-auditlog               RUNNING   pid 6463, uptime 0:03:17
fluentbit-kmsg                   STOPPED   Not started
fluentbit-metrics:cpu            RUNNING   pid 6466, uptime 0:03:17
fluentbit-metrics:df             RUNNING   pid 6471, uptime 0:03:17
fluentbit-metrics:disk           RUNNING   pid 6468, uptime 0:03:17
fluentbit-metrics:mem            RUNNING   pid 6472, uptime 0:03:17
fluentbit-metrics:mem_p          RUNNING   pid 6473, uptime 0:03:17
fluentbit-metrics:netif          RUNNING   pid 6474, uptime 0:03:17
fluentbit-systemd                RUNNING   pid 6478, uptime 0:03:17
fluentbit-thermal                RUNNING   pid 6480, uptime 0:03:17
netsniff:netsniff-enp1s0         STOPPED   Not started
prune:prune-pcap                 RUNNING   pid 6484, uptime 0:03:17
prune:prune-zeek                 RUNNING   pid 6486, uptime 0:03:17
supercronic                      RUNNING   pid 6490, uptime 0:03:17
suricata                         RUNNING   pid 6501, uptime 0:03:17
tcpdump:tcpdump-enp1s0           STOPPED   Not started
zeek:capa                        RUNNING   pid 6553, uptime 0:03:17
zeek:clamav                      RUNNING   pid 6512, uptime 0:03:17
zeek:logger                      RUNNING   pid 6554, uptime 0:03:17
zeek:virustotal                  STOPPED   Not started
zeek:watcher                     RUNNING   pid 6510, uptime 0:03:17
zeek:yara                        RUNNING   pid 6548, uptime 0:03:17
zeek:zeekctl                     RUNNING   pid 6502, uptime 0:03:17

Managing disk usage

In instances where Hedgehog Linux is deployed with the intention of running indefinitely, eventually the question arises of what to do when the file systems used for storing Malcolm’s artifacts (e.g., PCAP files, raw logs, extracted files, etc.). Hedgehog Linux provides options for tuning the “aging out” (deletion) of old artifacts to make room for newer data. These are configured during Configure Capture and are stored in the /opt/sensor/sensor_ctl/control_vars.conf configuration file. Editing this file manually should be done with care.

Verifying Traffic Capture and Forwarding

The easiest way to verify network traffic is being captured by the sensor and forwarded to Malcolm is through Malcolm’s Arkime Sessions interface.

If logged into the Malcolm desktop environment, click the Arkime icon (🦉) in the top panel. If connecting from another browser, connect to **https://**.

As Malcolm is using self-signed TLS certificates, users will likely have to confirm a browser exception to allow the self-signed certificates to proceed. Enter the credentials specified during the configure authentication process.

Arkime’s sessions view will be displayed. Filter on the node field to view records from a specific Hedgehog Linux sensor. In the search bar, enter node == hedgehoghostname (replacing hedgehoghostname with the hostname configured for Hedgehog Linux). See the Search Queries in Arkime and OpenSearch cheat sheet for more search syntax hints.

Arkime's Sessions view

Arkime’s sessions view with a filter on node

Arkime’s views button (indicated by the eyeball 👁 icon) allows overlaying additional previously-specified filters onto the current sessions filters. For convenience, Malcolm provides several Arkime preconfigured views including filtering on the event.provider and event.dataset fields. This can be combined with the node filter described above to verify different network log types (e.g., Arkime sessions, Zeek logs, Suricata alerts, etc.) are all being captured and forwarded correctly.

Malcolm views