Tell HN: CrowdStrike Falcon users, check for excess KernelModuleArchiveExt files
5 コメント
Ah Crowdstrike. One of the bigger problems we had at $company deploying the daemon to client servers was that there was (at the time) no config item to change the log file location. So we had a client who'd run out of disk space and IIRC Crowdstrike similarly refused to make any change. I think we "fixed it" by using GDB to change the outfile to a `grep -v` and into the same file.
I’m assuming this affects their older kernel module variant. Switch to their bpf version if you must use this snake oil
Unfortunately, no.
From what I've seen, CrowdStrike Falcon installations contain both the BPF components and the kernel module. (I think you can tell which one you're using: if falcon-sensor is running, it's the kernel module; if falcon-sensor-bpf is running, it's BPF.)
I manage systems running Debian, Ubuntu, RHEL, and Rocky. Newer and older, kernel and BPF. And unfortunately, this issue is present across all of them.
From what I've seen, CrowdStrike Falcon installations contain both the BPF components and the kernel module. (I think you can tell which one you're using: if falcon-sensor is running, it's the kernel module; if falcon-sensor-bpf is running, it's BPF.)
I manage systems running Debian, Ubuntu, RHEL, and Rocky. Newer and older, kernel and BPF. And unfortunately, this issue is present across all of them.
This is a heads-up for folks who run CrowdStrike Falcon on Linux servers, and particularly on Linux servers that were provisioned some time ago. It's a problem that CrowdStrike does not plan on fixing, and so I wanted to let others know before it causes your machines to hang.
You should have CrowdStrike Falcon installed at path /opt/CrowdStrike/. In that directory, you probably have one file whose name begins with "KernelModuleArchive", and many files whose name begins with "KernelModuleArchiveExt". That's the problem.
CrowdStrike appends a version number to every executable & library file. It does a good job of cleaning up old versions of almost all of its files. Except for KernelModuleArchiveExt.
I first noticed this happening when a virtual machine (with a small /opt partition) filled up /opt, and the system stopped responding. Turns out, /opt/CrowdStrike had filled up with 18 different KernelModuleArchiveExt files.
What is the fix? Well, our CrowdStrike admins opened a ticket with CrowdStrike, and we were told:
* Yes, the KernelModuleArchiveExt files are not being cleaned up automatically. Other files are being cleaned up automatically, but not the KernelModuleArchiveExt files.
* Will CrowdStrike release an update that cleans up the KernelModuleArchiveExt files? No.
* Will you put it on your roadmap to implement in the future? No.
* So, what should we do? If you want to clean them up, do it yourself.
If your site uses CrowdStrike uninstall protection, you cannot clean them up yourself without first getting a "maintenance token" from your CrowdStrike admins. Otherwise, deleting all KernelModuleArchiveExt files and restarting the CrowdStrike Falcon sensor works (it goes out and downloads the KernelModuleArchiveExt that it needs). Personally, though, I don't think we should have to do this.
Since CrowdStrike refuses to fix this, I wanted to let folks know, so you can check your systems. If you discover that this problem also affects you, I encourage you to open your own support ticket with CrowdStrike.