Linux - Software Lifecycle - Uninstall Kaspersky Software

What the Kaspersky removal Worklet does

This Automox Worklet™ uninstalls Kaspersky Endpoint Security for Linux (the kesl package) from every Linux endpoint under Automox management. The evaluation script detects the active package manager with command -v and queries the local package database using rpm -qa, dpkg-query -l, dnf list installed, yum list installed, or zypper search --installed-only. The endpoint is flagged for remediation whenever kesl is present in any of those stores.

The remediation script selects the matching package-manager command and runs it under sudo. RPM endpoints use rpm -e against the package name returned by rpm -qa | grep kesl. DNF and YUM endpoints use dnf remove -y kesl or yum remove -y kesl. Debian and Ubuntu endpoints use apt-get remove --purge -y kesl. SUSE endpoints use zypper remove -y kesl. The Worklet then deletes the residual configuration tree at /opt/kaspersky, /etc/opt/kaspersky, and /var/opt/kaspersky with rm -rf, which clears the kesl daemon binaries, definition databases, scan logs, and license material that the package manager leaves behind.

A post-remediation check re-runs the package query across every available manager and runs find /opt/kaspersky /etc/opt/kaspersky /var/opt/kaspersky -type d. The Worklet exits non-zero with "Uninstallation failed." on stderr if any artifact remains, so partial removals surface in Automox activity logs instead of going silent. The output is suitable for attaching to a compliance ticket as evidence that the sanctioned software has been retired from the endpoint.

Why remove Kaspersky from your Linux fleet

On June 20, 2024, the US Department of Commerce Bureau of Industry and Security issued a Final Determination prohibiting Kaspersky Lab and its affiliates from providing antivirus software and cybersecurity products to US persons. The determination, paired with the addition of three Kaspersky entities to the BIS Entity List, made continued operation of Kaspersky agents in US-regulated environments a sanctions exposure rather than a vendor-selection question.

Federal contractors, FedRAMP environments, and any organization that flows down US export controls to its Linux fleet must produce evidence that the kesl daemon is no longer running and that the /opt/kaspersky tree is gone. CISA's Binding Operational Directive 17-01 still applies to federal and federal-adjacent fleets. Running kesl alongside a replacement agent also generates on-access scan duplication and I/O contention on busy hosts, so the operational case and the compliance case align.

This Worklet detects kesl across RHEL, CentOS, Rocky, Alma, Ubuntu, Debian, and SUSE, runs the distro-correct removal command, deletes residual /opt/kaspersky directories, and re-checks the state on each evaluation pass until every Linux server in the fleet reports clean.

How sanctioned Kaspersky removal works

1. Evaluation phase: The script detects the available package manager with command -v rpm, command -v apt, command -v dnf, command -v yum, and command -v zypper, then queries the matching database for the kesl package using rpm -qa, dpkg-query -l, dnf list installed, yum list installed, or zypper search --installed-only. If kesl appears in any package store, the script exits 1 and remediation is scheduled. A clean endpoint exits 0 and is reported as compliant with the sanctioned-software removal policy.

2. Remediation phase: The remediation routine runs the package-manager-appropriate command (apt-get remove --purge -y kesl, yum remove -y kesl, dnf remove -y kesl, sudo rpm -e against the package returned by rpm -qa | grep kesl, or zypper remove -y kesl). It follows that step with rm -rf /opt/kaspersky /etc/opt/kaspersky /var/opt/kaspersky. The script then re-queries every available package database and runs find /opt/kaspersky /etc/opt/kaspersky /var/opt/kaspersky -type d. If any check still finds Kaspersky artifacts, the script writes "Uninstallation failed." to stderr and exits 1, so the failure surfaces in the Automox activity feed. A successful run leaves the endpoint with no kesl package, no kesl process, and no Kaspersky filesystem footprint.

Kaspersky removal requirements

• Linux endpoint running RHEL, CentOS, Rocky, Alma, Fedora, Oracle Linux, SUSE, openSUSE, Debian, or Ubuntu with rpm, apt, dnf, yum, or zypper available on the default PATH

• Root or sudo execution context for the Automox agent so package removal and rm -rf on /opt/kaspersky, /etc/opt/kaspersky, and /var/opt/kaspersky succeed

• Kaspersky Endpoint Security for Linux (kesl) installed on the endpoint, since the evaluation script keys on the kesl package name and exits 0 when the package is absent

• A replacement endpoint protection agent (CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint on Linux, or ClamAV with a managed signature pipeline) deployed before or during the same maintenance window, so the endpoint retains anti-malware coverage

• Scheduled maintenance window for endpoints that run kesl with an active on-access scan, because the package transaction briefly increases I/O while the scanner is removed

• Approved change record citing the BIS Final Determination of June 20, 2024 or the internal sanctions-compliance policy that authorizes the removal, retained alongside the Worklet run output

Expected state after Kaspersky removal

After a successful run, the kesl package is absent from every supported package database on the endpoint. rpm -qa | grep kesl returns no rows on RPM-family systems, dpkg-query -l | grep kesl returns no rows on Debian-family systems, and zypper search --installed-only kesl returns an empty result on SUSE. The three filesystem paths /opt/kaspersky, /etc/opt/kaspersky, and /var/opt/kaspersky no longer exist, so ls /opt/kaspersky returns "No such file or directory" and find /etc/opt /var/opt -name kaspersky finishes with no output.

Validate runtime state with ps -ef | grep -i kesl and systemctl list-units --type=service | grep -i kaspersky; both commands should return no Kaspersky processes or units once the package transaction completes. For audit evidence, capture the stdout of the post-remediation run along with the Automox activity log entry showing exit code 0, and attach both to the change record citing the BIS Final Determination. Subsequent evaluation runs report the endpoint as compliant and apply no further remediation, because the evaluation script finds no kesl package in any supported manager.

If a follow-up evaluation flips the endpoint back to non-compliant, the typical causes are a reimage from a golden image that still contains the kesl package, a manual reinstall by an engineer unaware of the sanctions-compliance policy, or a backup restoration that re-populates /etc/opt/kaspersky. A weekly Automox policy run catches the regression before it appears in the next compliance review. Pair this Worklet with one that audits installed packages so the source of any reinstall is identifiable from Automox alone.