Getting Started

In this how-to guide, we’ll walk through how to configure rsyslog to send data to your CrowdStrike Falcon^® LogScale repository. All you’ll need to get started is a Falcon LogScale instance (either self-hosted or through LogScale Cloud), a LogScale repository and an ingest token.

We’ll use LogScale Cloud with a Falcon LogScale Community Edition (LCE) account. If you don’t have a free LCE account yet, you can sign up for one here. Typically, your account request will be approved within two business days. (Until recently, Falcon LogScale was named Humio, so you may encounter some Humio references in the UX.)

For our demo, we’re running a Fedora 36 virtual machine. However, the steps for shipping logs to LogScale should be similar for most modern Linux-based operating systems and LogScale instances.

Step 1: Add a New Repository

Once you’ve logged into LogScale, you’ll need to create the repository where your log data will be shipped. Navigate to Repositories and Views and click + Add New.

Fill out the required fields, and then save the repository configuration.

Step 2: Create an Ingest Token

Now that the repository is created, we’ll need to provide rsyslog with an ingest token to use when authenticating with LogScale. In our repository, we navigate to Settings, and then to Ingest Tokens. We click on + Add Token.

When creating a token, you’ll be asked to provide a token name and select a parser. The list of built-in parsers for LogScale can be found here. For this example, we choose the syslog parser. We copy the value of the token to a safe place. We’ll be using the ingest token in the next step.

Step 3: Install Rsyslog and the Elasticsearch plugin

Now, we need to install rsyslog and the Elasticsearch Output Module, rsyslog-elasticsearch, which will enable us to format the logs in a LogScale-supported way.

$ sudo dnf install -y rsyslog rsyslog-elasticsearch

We need to tell rsyslog how to convert the logs into the Elasticsearch format before they get shipped to our repository. LogScale recommends keeping a simple configuration in /etc/rsyslog.d/33-logscale.conf that contains the following configuration:

module(load="omelasticsearch") 
template(name="logscaletemplate" type="list" option.json="on") {
  constant(value="{")  
     constant(value="\"@timestamp\":\"") property(name="timereported" dateFormat="rfc3339") 
     constant(value="\",\"message\":\"") property(name="msg") 
     constant(value="\",\"host\":\"") property(name="hostname") 
     constant(value="\",\"severity\":\"") property(name="syslogseverity-text") 
     constant(value="\",\"facility\":\"") property(name="syslogfacility-text") 
     constant(value="\",\"syslogtag\":\"") property(name="syslogtag") 
     constant(value="\",\"name\":\"") property(name="programname") 
     constant(value="\",\"pid\":\"") property(name="procid") 
     constant(value="\"}") 
} 
*.* action(type="omelasticsearch" 
    server="$YOUR_LOGSCALE_URL/$YOUR_LOGSCALE_INGEST_PORT" 
    template="logscaletemplate" 
    uid="logscale-tutorial" pwd="$YOUR_INGEST_TOKEN" 
    bulkmode="on" 
    usehttps="on")

There is a lot packed into this configuration, so let’s dissect what’s happening.

• module(load=”omelasticsearch”) tells rsyslog to load the output module, which came from the rsyslog-elasticsearch package we installed earlier.
• template(name=”logscaletemplate” type=”list” option.json=”on”) creates a new log formatting template named logscaletemplate. The template is created through a list of constant and property statements and will format the string to be suitable for json.
• constant() defines a literal text output in the template. For example:
  • constant(value=”{“) will output a literal { in the log, which makes sense in our case since we’re constructing a JSON-formatted log.
• property() statements are where the actual data substitution happens when converting to our new template. For example:
  • property(name=”msg”) will take the msg value from the log and insert it when the template gets evaluated.
• *.* is the log selector. In this case, we’re matching everything so we can send it all to LogScale.
• action() is the action to take when a log is matched. In our configuration, the action will be taken for all logs (since we use *.* ). Most of the fields included in the action() clause are self-explanatory, telling rsyslog what type of output module to use or where to send the processed logs.

Before starting up rsyslog with this configuration, we need to replace the values unique to our LogScale instance:

• $YOUR_LOGSCALE_URL is the endpoint for your LogScale instance. Since we are using an LCE account, our URL should be https://cloud.community.humio.com. If you have a different type of account, you can reference the endpoints documentation from LogScale for the URL to use.
• $YOUR_LOGSCALE_PORT is 443. If you are running a self-hosted instance of LogScale, then you’ll also need to ensure that you’ve configured your instance with the ELASTIC_PORT environment variable.
• $YOUR_INGEST_TOKEN is the value of the ingest token that we created and copied in our previous step.

With our configuration all set, we’re ready to restart rsyslog and verify that it’s running.

$ systemctl restart rsyslog.service
$ sudo systemctl status rsyslog.service

● rsyslog.service - System Logging Service
     Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2022-07-31 01:28:25 UTC; 3min 14s ago
       Docs: man:rsyslogd(8)
             https://www.rsyslog.com/doc/
   Main PID: 7128 (rsyslogd)
      Tasks: 3 (limit: 19155)
     Memory: 27.6M
        CPU: 213ms
     CGroup: /system.slice/rsyslog.service
             └─7128 /usr/sbin/rsyslogd -n

Jul 31 01:28:25 fedora systemd[1]: Starting rsyslog.service - System Logging Service...
Jul 31 01:28:25 fedora systemd[1]: Started rsyslog.service - System Logging Service.
Jul 31 01:28:25 fedora rsyslogd[7128]: [origin software="rsyslogd" swVersion="8.2204.0-2.fc36" x-pid="7128" x-info="https://www.rsyslog.com"] start
Jul 31 01:28:25 fedora rsyslogd[7128]: imjournal: No statefile exists, /var/lib/rsyslog/imjournal.state will be created (ignore if this is first run): No such file or dire>
Jul 31 01:28:26 fedora rsyslogd[7128]: imjournal: journal files changed, reloading...  [v8.2204.0-2.fc36 try https://www.rsyslog.com/e/0 ]

We’ve successfully configured rsyslog!

Step 4: Check the Repository for Data

Our final step is to check our LogScale repository to verify that logs are being ingested. We navigate to our repository and enter count(field=”syslogtag”) into the search box. This will return a total count of ingested logs. Depending on how busy your forwarded system is, the end result should look something like this:

It looks like rsyslog is successfully shipping log data to LogScale. From here, you can begin querying data, building out visualization dashboards, and setting up automated notifications and alerts. 

Wrapping Up

We’ve covered a lot of steps and learned some interesting details about log forwarding to LogScale with rsyslog. Let’s take a moment to review.

• We installed rsyslog and rsyslog-elasticsearch on our virtual machine. This gave us the base logging provider and an extension to massage the logs into a format that LogScale can ingest.
• We created a configuration file to specify how rsyslog will convert a regular log into an Elasticsearch-style log that can be forwarded to LogScale. We configured rsyslog to do this for all logs.
• We started up rsyslog and then confirmed in our LogScale repository that the logs we forwarded were ingested successfully.

LogScale and rsyslog are both powerful and flexible. If you’re wondering about what might be good next steps to take, you might want to look into some of rsyslog’s plugins. If you really want to level up your logging, you may even try creating your own rsyslog template and coupling that with a custom LogScale parser!

Happy logging!

Additional Resources

• Read why CrowdStrike Falcon Insight XDR is the next frontier for detection and response.
• See how CrowdStrike is driving the convergence of security and observability with Falcon LogScale and Falcon Complete LogScale.
• Watch a Falcon Insight XDR demo.
• Get a full-featured free trial of CrowdStrike Falcon Prevent^™ and see for yourself how true next-gen AV performs against today’s most sophisticated threats.
• Contact us to learn more about Falcon Insight XDR and Falcon LogScale.