9/10/2020 Knowledge Article

Troubleshooting Linux Sensors - Communications Issues

Title Troubleshooting Linux Sensors - Communications Issues
Details
Troubleshooting Linux Sensors → Communications Issues
This article is a sub-article of Troubleshooting Linux Sensors. We advise consulting that parent article in case there are
other Linux troubleshooting articles that might apply to your situation.

Canonical Documentation
The content of this article is derived from the Falcon Sensor for Linux deployment guide, which can be found in the
Falcon console under Support → Docs. This document is updated by our product management and technical writing
teams, and should be considered canonical. If there is a discrepancy between the information found in this KB article and
those guides, the guides are authoritative.

Service Dependencies
Supported version of OpenSSL
libssl
libc
libcrypto
these runtime services:

network
systemd
local-fs
sysinit
multi-user
shutdown

Most of these are resolved during installation with dependency checks.

Whitelisting Falcon Endpoints

Completely dependent on your unique network architecture, it may become necessary to whitelist our two cloud endpoints
which the sensor communicates with to allow traffic through your network perimeter or interior. These two endpoints each
have a DNS name, pointing to an Elastic Load Balancer in AWS with a FQDN, and each ELB in turn is backed by a special
pool of static IP addresses the ELBs may scale into at any time.

Some organizations' network configurations allow them to simply whitelist the endpoints' DNS names and/or ELB FQDNs,
while other configurations may need all of the static IPs backing the endpoints whitelisted. If whitelisting by IP is necessary,
all IP's in the pools should be included.

Troubleshooting your communications issues should include working with your own organization's network team to ensure
that sensor traffic is whitelisted as documented in the KB article, "Sensor Communication Information".

Certificate Pinning Interference / SSL Inspection

The Falcon sensor uses certificate pinning to defend against man-in-the-middle attacks. Some network configurations,
such as deep packet inspection, interfere with certificate validation. The Falcon Sensor will detect and disallow any such
eavesdropping.

https://supportportal.crowdstrike.com/articles/Knowledge/Troubleshooting-Linux-Sensors-Communications-Issues/p 1/4
9/10/2020 Knowledge Article
Disable deep packet inspection (also called "HTTPS interception," "TLS interception," or "SSL inspection") or similar
network configurations. Common sources of interference with certificate pinning include antivirus systems, firewalls, or
proxies.

Please ensure that no SSL inspection is occurring on Falcon traffic. If you must utilize SSL inspection in your environment,
you must whitelist all Falcon traffic from SSL inspection.

You can confirm this by examining the certificate chain using OpenSSL, which you may need to install first. Please see the
article, "Using OpenSSL to Find Certificate Chain Issues," for instructions on how to do this.

Confirm Proxy Settings

If your hosts or applications require a proxy to connect to the Internet, make sure that you have factored that into your
Falcon installations. The details can be found in the Falcon Sensor for Linux deployment guide under Support → Docs,
under Optional: Configure a Proxy.

Confirm the Host Connectivity to Falcon Host Cloud Endpoints

The most basic checks involve proving that the local host can reach the Falcon cloud endpoints, which exist in AWS.

CURL
Example command syntax:

curl -x your_proxy:your_port https://ts01-b.cloudsink.net

curl -x your_proxy:your_port https://ts01-b.cloudsink.net:443
curl -v https://ts01-b.cloudsink.net
curl -v https://ts01-b.cloudsink.net:443

Note: The examples above assume that your Falcon instance is hosted in our commercial cloud. If you’re on a different
cloud – for example, GovCloud or EU Cloud – you’ll need to change the server you test against. See “Sensor
Communication Information” for other options that fit your specific cloud.

OpenSSL
Following the guidance from the article "Using OpenSSL to Find Certificate Chain Issues" can also be used to verify
connectivity.

Check SSL and TLS Settings

What Is TLS and How Does It Vary From SSL?

TLS stands for Transport Layer Security Protocol. As with SSL, it is also a means to protect data in motion. TLS and SSL
are so closely related TLS 1.0 was referred to as SSLv3.1. The handshakes are similar, however instead of using MAC in
its CipherSuite like SSL, it uses keyed-hash message authentication code (HMAC). Using HMAC allows TLS to use a
variety of hash functions and not just MD5 or SHA. TLS also has a faster method of taking client information from previous
handshake messages to come to a CertificateVerify message faster. ClientVerify is a signature of a previous handshakes
using the client certificate as well as its private key. Lastly one of the bigger differences between TLS and SSL are the
cipher types. AES cipher suites were integrated in TLS providing advanced encryption.

Security and SSL/TLS

At this time SSLv3 and TLS 1.x are so close in function that the real concern is more relative to older versions of SSL vs
SSLv3/TLS 1.0+.

The preferred connection protocol at this time is TLS 1.2.

https://supportportal.crowdstrike.com/articles/Knowledge/Troubleshooting-Linux-Sensors-Communications-Issues/p 2/4
9/10/2020 Knowledge Article
SSLv2 and SSLv3 are no longer supported on any operating system. In terms of security, disabling SSLv2 is advised by
most companies in the security sector as well as OpenSSL, and even SSLv3 is being criticized for its vulnerabilities.

CrowdStrike and How This is Relevant

CrowdStrike sensors will all connect using the most secure and available security protocol. For Mac and Linux, these
Sensors connect at TLS 1.2, which is currently the most secure cipher suite. We do not support or communicate on
SSLv2 or SSLv3. You will need to ensure you have SSLv2.0 and SSLv3.0 disabled as well as enable the stronger
protocol such as TLSv1.2

Where To Find Your SSL/TLS Settings

SSL settings will vary in location between .deb installations (Ubuntu) and .rpm installations (CentOS/RHEL) systems. They
can be verified at the following locations (assuming default config paths, which can be customized):

.rpm installations:
/etc/httpd/conf.d/ssl.conf
.deb installations:
/etc/apache2/mods-enabled/ssl.conf

Run Falcon-Diagnostic Script & Collect Logs

We provide a custom diagnostic information gathering script in the form of falcon-diagnostic.sh which aids in collecting
relevant information about your system and some log collection. Whenever you are working with support, please provide
an output of this script.

Collect TCPDump of Traffic

When troubleshooting communications issues, it often becomes necessary to collect a traffic dump for analysis. We
always recommend analyzing these internally with your own network experts first in case the cause of an issue is
immediately apparent. However, when escalating to CrowdStrike Support, our own Technical Support Engineers, Technical
Account Managers, and Sensor Engineers we escalate to will also need these dumps.

1. Open two ssh sessions to the server.

2. On the first session: run the tcpdump. There are two approaches; use whichever you prefer:

$ sudo tcpdump -i any -s0 -w HOSTNAME.pcap

Or,
$ sudo tcpdump -i any -s0 dst <FALCON ENDPOINT> -w HOSTNAME.pcap
Replace <FALCON ENDPOINT> with an appropriate DNS name. Use either the ts01-b or
lfodown01-b endpoints for your cloud from “Sensor Communication Information”. Example, if your
instance is in our Commercial Cloud:
$ sudo tcpdump -i any -s0 dst ts01-b.cloudsink.net -w johndoe-
laptop.mydomain.com.pcap

3. On the second session: run the sensor stop and start commands in sequence:

Hosts with SysVinit:

1. $ service falcon-sensor stop

2. $ service falcon-sensor start

Hosts with Systemd:

1. $ systemctl stop falcon-sensor

2. $ systemctl start falcon-sensor

4. Back to the first session, stop the tcpdump with CTRL+C.

https://supportportal.crowdstrike.com/articles/Knowledge/Troubleshooting-Linux-Sensors-Communications-Issues/p 3/4
9/10/2020 Knowledge Article

Engaging Support
Troubleshooting Linux Sensors can be a complex process, and we hope this guide has provided you enough to isolate
your issue so you can find a solution. However, if you can't, CrowdStrike Support and our Engineering teams are standing
by to guide you through the process.

The biggest thing to understand is that this guide was written based on our own run-books: if you see a step or request for
hard data in this guide for a scenario that applies to your situation, we're probably going to request it of you.

General Support Engagement Tips

Here are a few general tips about engaging Support about Linux Sensor issues:

Be specific, and provide the details. A vague statement that it doesn't work will be responded with a request
for additional, basic details first. Provide relevant details: Hostnames, OS versions and kernel versions, times
(with timezones), sensor version levels.
Be conservative with screenshots, and watch the cropping. Unless it's important to see how a thing is
presented, don't use a screenshot when raw text output, or a permalink to a specific Falcon console report, or
query string (as examples) will do the job more effectively. We can't copy/paste and search through a screenshot
of text, or reproduce your experience. And if the screenshot is over-cropped, we (literally) can't see the bigger
picture. Provide screenshots only when a screenshot makes more sense than other formats.
When describing a process you're following, provide repro details. The KB article, "Best Practices for
Describing Your Support Issues," will describe how to write solid repro steps.
Append the hostnames that output files come from to the output filenames. If you generate a TCPDump
file, or export falcon-diagnostic script output, rename these files with the source hostname so we know where it
came from: hostname-TCPDump.DATE.pcap, hostname-falcon-diag.DATE.tar.xz are examples.

URL
Troubleshooting-Linux-Sensors-Communications-Issues
Name

https://supportportal.crowdstrike.com/articles/Knowledge/Troubleshooting-Linux-Sensors-Communications-Issues/p 4/4