Tell HN: CrowdStrike Falcon users, check for excess KernelModuleArchiveExt files

Hello!

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.

9 points | by CaliforniaKarl 1 day ago

3 comments

  • chaps 1 day ago
    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.
  • broknbottle 1 day ago
    I’m assuming this affects their older kernel module variant. Switch to their bpf version if you must use this snake oil
    [-]
    • CaliforniaKarl 1 day ago
      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.

  • homeonthemtn 1 day ago
    Anyone have alternatives to clowdstrike they liked?
    [-]