https://itsfoss.com/news/kaspersky-for-linux/
Is Kaspersky for Linux the security solution we've been waiting for? Or is it just security theater for paranoid penguins?
The Linux ecosystem is facing increasing pressure from threat actors, who are getting more clever day-by-day, threatening critical infrastructure worldwide. Servers powering essential services, industrial control systems, and enterprise networks all rely on Linux, and these attackers know it.
What was once considered a relatively safe ecosystem is now a lucrative target. 🥲
This brings us to Kaspersky, the Russian cybersecurity firm with a reputation. The company was banned from selling its antivirus software and cybersecurity products in the U.S. back in July 2024.
But for users outside the U.S., Kaspersky just announced something interesting. They are bringing antivirus protection to home Linux users. Though, it remains to be seen, whether this addresses genuine security needs or if it's just security theater for worried penguins.
Kaspersky for Linux: What Does it Offer?
Kaspersky has expanded its consumer security lineup to include Linux. This marks the first time their home user products officially support the platform. The company adapted their existing business security solution for home users. Support covers major 64-bit distributions, including Debian, Ubuntu, Fedora, and RED OS.
Depending on the plan you opt for, the feature set includes real-time monitoring of files, folders, and applications to detect and eliminate malware. Behavioral analysis detects malware on the device for proactive defense.
Removable media like USB drives and external hard drives get scanned automatically upon connection. This prevents the spread of viruses across devices and networks.
Anti-phishing alerts users when attempting to follow phishing links in emails and on websites. Online payment protection verifies the security of bank websites and online stores before financial transactions.
Anti-cryptojacking prevents unauthorized crypto mining on devices to protect system performance, and AI-powered scanning blocks infected files, folders, and applications upon detecting viruses, ransomware trojans, password stealers, and other malware.
Though, there is one important thing to consider: Kaspersky for Linux isn't GDPR-ready, so keep this in mind if you are an EU-based user concerned about data protection compliance.
Get Kaspersky for Linux
An active paid subscription is required to download and use Kaspersky for Linux. A 30-day free trial is available for users who want to test before committing to a paid plan. Both DEB and RPM packages are provided for easy installation.
The official installation guide contains detailed setup instructions.
Via: Phoronix
(Score: 5, Insightful) by JoeMerchant on Saturday November 22, @12:36AM
I didn't trust Kaspersky 20 years ago... now? It hasn't done anything to earn my trust in the meantime.
🌻🌻🌻 [google.com]
(Score: 2) by Gaaark on Saturday November 22, @01:30AM
Да, у нас нет бананов. У нас нет бананов для Путина!
(Da, u nas net bananov. U nas net bananov dlya Putina!)
Have not used, will not.... especially now.
--- Please remind me if I haven't been civil to you: I'm channeling MDC. I have always been here. ---Gaaark 2.0 --
(Score: 5, Insightful) by HiThere on Saturday November 22, @01:49AM (1 child)
If someone I trust really vouches for it...which means they not only have the capability of understanding the code, but they have actually studied it, then I would consider it.
I practice, this would mean the code would need not only to be open source, but also interesting to people that I consider reliable in that area.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 5, Funny) by JoeMerchant on Saturday November 22, @02:12AM
Only person I ever knew who used it was an alcoholic CEO, he figured the Russians know more about malware than most...
🌻🌻🌻 [google.com]
(Score: 3, Interesting) by Arthur Wellesley on Saturday November 22, @01:56AM (5 children)
The problem is what malware protection to use on Linux. I have tried ClamAV, but it is really only useful for scanning files/folders -- it does not provide active protection. And I don't have the skills to implement my own firewall. I have used Kaspersky on Windows machines, and was impressed with several of its features. That it is compromised by its Russian connections is a problem, of course, but the same is the case for any security software -- who can guarantee that their local security agencies have not tampered with the software? Anyone got some suggestions?
(Score: 5, Interesting) by JoeMerchant on Saturday November 22, @02:15AM
> And I don't have the skills to implement my own firewall.
Ask Claude. No, really. And be patient, when things don't go as you want describe the issue to Claude in detail, copy-paste logs to Claude for analysis. If you're interested, you'll be learning how to configure a firewall for yourself along the way. If you're not interested, you'll still end up with a reasonably well configured firewall.
🌻🌻🌻 [google.com]
(Score: 4, Interesting) by RS3 on Saturday November 22, @03:23AM
Two separate things here. Firstly, most people are already behind a firewall. If you're referring to a home network, you likely have some kind of gateway (router) that you connect to fiber or coax to the Internet, and most are firewall by default. Some older gateways might not have had firewall set up by default.
In case you don't know, IP addresses are like a zip code. Within a zip code you have PO boxes. In IP speak, we have ports. Linux, Windows, MacOS, other OSes have some kind of software that "listens" to the IP connection. When a packet comes in, said software looks at the port number in the packet and sends it to software that handles whatever business that packet has. It might be an html request on port 80 or 443, and if your computer is running a webserver software then that software will respond accordingly. You can web search for IP port numbers and you'll get huge lists of the many functions for each.
So firewall means those ports are blocked. IE, if someone on the Internet tries to send packets to your IP address, they'll do nothing. Unless you've intentionally set up the router software to open that port to the outside world, and relay that traffic to something on your internal network.
For example I admin some servers. I have ports open only for the services the servers are supposed to respond to from the Internet. But, there are services, such as Windows file sharing (CIFS) and Linux Samba, that are open to the internal network, but those ports are closed to the Internet. (Samba is the Linux software that allows you to share files with Windows machines).
Malware protection is a different thing. You could download an infected file, or receive an infected email attachment or many other ways malware could get in. Yes, you'd need a scanner constantly scanning.
For several years there was a great thing from McAfee (yes really) called "Stinger" that ran in the background and only watched a bunch of core Windows system files. If anything tried to change one of them, Stinger would halt the program and pop up an alert. It worked, and did not bog the system down with constant scanning. I don't know the full story but now "Trellix" owns it and they 100% trashed it. Never even try their crap because it installs a bunch of crap that refuses to uninstall.
I'm not expert on the many anti-malware packages out there. I occasionally run clam scan, or scan a file on jotti or virustotal. There is clamd for Linux. I've run it some years ago but I forget it if can be configured to watch for activity and only scan things that are being changed. Time to ask an AI...
(Score: 1, Interesting) by Anonymous Coward on Saturday November 22, @06:36AM (1 child)
IMO you are better off sandboxing applications that handle untrusted inputs e.g., pdf viewers, web browsers (including wget/curl), image viewers, etc., than using an unreliable virus scanner.
E.g., if I view a pdf in my browser downloads directory with atril, atril cannot access any of my private documents, ssh keys, password database, etc. I have to invoke atril as 'atril-priv' (uses a different jailing profile) to access private data like my taxes. And, atril never has access to the network. For video players like vlc, mplayer, etc., they normally have no access to network, but if invoked, e.g., 'vlc-net', they can access network. None ever have access to any of my documents, ssh keys, password database, etc. Standard vim with no plugins has access to everything. Neovim with plugins is restricted to just a couple directory hierarchies (I don't trust the plugins, some have a zillion dependencies). It took a while, but nearly everything is jailed with custom firejail profiles on my systems now (some things like tar are hard to effectively sandbox since they need to be able to extract files anywhere). Occasionally things break (e.g., after a recent update anything using gtk stopped being able to print until jail profile rules were modified), but maintenance has not been too bad.
Firejail has its warts, but is possible to create very restrictive jails (the bundled ones vary greatly in quality). There are other options, like bubblewrap, but firejail is the most complete. Firejail uses a combination of namespaces, capabilities, seccomp and apparmor for sandboxing.
The threat, on linux, is so remote that maybe it is not worth the trouble to take any measures. Most people probably have never seen linux malware / malformed files targeting applications running on linux, in the wild. But, still, I feel more secure knowing my viewer is sandboxed when I open an epub or pdf downloaded from libgen.
(Score: 0) by Anonymous Coward on Sunday November 23, @08:22AM
Sandboxing is like "solving" the Halting Problem by making sure the code halts whether it's coded that way or not. 🤣
(Score: 1) by skaplon on Monday November 24, @03:05PM
Take a look at ESET. I only use it on windows and it is good there, haven't tried their linux solution
(Score: 1, Informative) by Anonymous Coward on Saturday November 22, @05:20AM
I used to use Kaspersky in the early '00s on the linux email gateways for a college I worked at. At the time, Kaspersky had the best results in independent testing on known malware and low false positives. We also used Avira, on the mail gateways, which had the best test results for heuristics with low false positives. This was to protect downstream windows clients (we also had mac and linux clients, but the only malware we ever saw was for windows).
(Score: 5, Informative) by Anonymous Coward on Saturday November 22, @05:42AM (6 children)
Stop debating which file scanner to run on Linux. If you are relying on ClamAV signatures to catch a modern reverse shell or a rootkit, you are already owned. Traditional AV on Linux detects maybe 2% of threats, which are mostly Windows malware sitting in your mail spool.
Real Linux security requires a stack that ignores file signatures and monitors kernel-level behavior. We need to treat Linux memory forensics just like Windows. This means scanning volatile memory for fileless malware using calls like memfd_create to execute ELF binaries directly from RAM without ever touching the disk, or detecting ptrace abuse for process injection. Since Linux lacks a direct AMSI equivalent, effective protection must use eBPF uprobes to hook into interpreters like Python, Perl, and Ruby at runtime to de-obfuscate and analyze scripts before execution.
Identity defense on Linux is not about lsass.exe but about hardening the ssh-agent socket against hijacking and monitoring access to /etc/shadow or Kerberos ccache files. We need to flag anomalous user behavior such as impossible travel scenarios where a root login occurs from two geographies simultaneously, or token manipulation within SSSD.
You need strict process genealogy that maps the entire execution chain. It flags illogical parent-child relationships, such as a web server process like nginx spawning a shell via /bin/sh. This extends to GTFOBins detection, flagging legitimate tools like awk or openssl used to initiate outbound network connections. Deception technology plays a massive role here by planting canary files in /tmp, fake AWS credentials in environment variables (honeytokens), or dummy .ssh/config entries. If a process touches them, it is an immediate high-fidelity IOC.
Network isolation and C2 hunting must correlate outbound traffic against threat intel for C2 beaconing and DGA domains, while specifically watching for lateral movement via SSH tunneling or RPC scanning. Automated remediation should go beyond killing the process; it needs to integrate with Netfilter/iptables to isolate the host immediately and potentially trigger filesystem snapshots on ZFS, Btrfs, or LVM to rollback encryption changes automatically.
Looking forward, the future of Linux security is moving toward eBPF-based LSM (Linux Security Modules) enforcement. Instead of just observing, we will see logic that preemptively blocks syscalls based on behavioral context without the overhead of traditional kernel modules. We should also expect deeper integration with container runtimes to detect namespace breakouts and container escapes by correlating host kernel telemetry with container IDs, essentially creating an immune system that understands the difference between a microservice behaving normally and one that has been compromised.
(Score: 0) by Anonymous Coward on Saturday November 22, @01:01PM (1 child)
Are these the kind of things SELinux does, or is that a different approach?
(Score: 1, Informative) by Anonymous Coward on Saturday November 22, @11:16PM
You are conflating a lock with a security camera. SELinux is a Mandatory Access Control (MAC) system. It acts as a rigid preventative mechanism. It does not hunt. It does not analyze behavior over time. It only enforces pre-defined policy rules.
The contrast is between enforcement and observability.
Think of SELinux as a static list of permissions. It assigns a label to every file and process. It then checks a lookup table to see if Label A can touch Label B. If the policy says httpd_t cannot write to shadow_t then the kernel blocks the syscall. This is vital for hardening. It is not detection.
Modern XDR and EDR solutions like CrowdStrike or Huntress rely on telemetry and context. They ask different questions.
If you have a sloppy policy that allows your web server to execute /bin/bash then SELinux will permit the connection every time. It will not care that the shell was spawned by an unknown IP address at 3 AM. It will not care that the shell immediately tried to curl a known C2 domain. A behavioral engine would flag this immediately because it correlates the process ancestry with network activity.
SELinux in part fails a modern security stack
SELinux is blind to the "living off the land" techniques we discussed earlier.
We talked about memfd_create. If a process has the right to allocate memory and execute from it then SELinux generally steps out of the way. It does not scan that memory block for malicious ELF headers or shellcode patterns.
Threat actors use legitimate tools like awk or python to move laterally. If your administrator needs these tools then the SELinux policy must allow them. It cannot distinguish between an admin running a script and an attacker running a reverse shell using the exact same binary.
SELinux protects the ssh-agent socket file from being read by unauthorized processes. It does not notice if a valid user token is being used to authenticate to fifty servers in under a minute. That requires an Identity Threat Detection and Response (ITDR) layer to parse logs and find anomalies.
It's a matter of the correct stack.
You cannot replace one with the other. You need both.
Use SELinux to reduce the blast radius. If an attacker compromises a container or a service then SELinux prevents them from escaping to the host filesystem. It is your containment wall.
Use eBPF and Auditd for the actual threat hunting. You need a collector that streams syscalls to a SIEM or a data lake. You then build detection logic on top of that stream to mimic the "CrowdStrike" model on Linux.
Required Linux Telemetry for XDR
Build your defense in depth. SELinux locks the doors. Your EDR solution watches the hallways for people who picked the lock.
(Score: 3, Informative) by shrewdsheep on Saturday November 22, @02:04PM (1 child)
What you write sounds plausible and insightful. I also belief that future defense are statistical. The normal behavior of a system can be measured in terms of distributions and deviation therefrom should triggers alters/countermeasures.
However, you used a bit too much jargon for me. Would you care to explain the following?
How could hooks into interpreters (what you call eBPF uprobes) help to deobfuscate code?
What is C2 hunting and beaconing?
What are DGA domains?
Thank you in advance.
(Score: 3, Interesting) by Anonymous Coward on Saturday November 22, @11:07PM
Statistical baselines are indeed the future. Industry moved away from rigid signatures in the Windows world years ago with tools like CrowdStrike and SentinelOne. It is time Linux caught up. We simply apply those same behavioral concepts to a different kernel.
eBPF Uprobes and De-obfuscation
Interpreted languages like Python, Perl, or Ruby are often blind spots for security tools. Attackers know this. They write malicious scripts and then "obfuscate" them. They use encoding like Base64 or heavy encryption to turn the readable code into a jumbled mess of random characters.
A file scanner looks at this mess on the disk and ignores it because it does not match a known virus signature.
However, that code cannot run as a jumbled mess. The interpreter must decrypt it back into plain text instructions in memory right before execution. This is where eBPF comes in.
We attach an "uprobe" (user-space probe) directly to the internal function of the interpreter that handles code execution. We essentially bug the room where the script is read. We wait until the script decrypts itself in memory. Then we capture the clean, malicious code the millisecond before it runs. This renders their encryption completely useless.
C2 Hunting and Beaconing
C2 stands for Command and Control. Once an attacker compromises a server, they need a way to send it instructions. This connection is the C2 channel.
Smart malware does not keep this connection open permanently. A permanent connection is easy to spot and block. Instead, the malware uses "beaconing."
The compromised machine sleeps for a set period. It wakes up briefly to send a small signal (a beacon) to the attacker asking for work. It then goes back to sleep. To hide this rhythm, they add "jitter" or random time delays.
Hunting for this means looking at network traffic metadata. You ignore what the data says and look at the behavior. You look for connection attempts that happen with mechanical regularity or exhibit specific size patterns distinct from normal user traffic.
DGA Domains
DGA stands for Domain Generation Algorithm. This is how attackers survive when defenders block their websites.
In the old days, malware would try to connect to a single hardcoded site like bad-hacker-site[.]com. Defenders would just block that domain at the firewall. The malware would then die.
Now, the malware contains an algorithm. This algorithm mathematically generates thousands of random domain names every day. They look like xkyz-123-ab[.]com or gqwe-555-zz[.]net. The attacker only needs to register one of these thousands of domains to succeed. The malware tries to connect to the list one by one until it finds the live one.
We detect this by watching DNS requests. If a server suddenly tries to resolve hundreds of nonsensical domain names in a row, it is running a DGA. It is trying to find its command server.
(Score: 3, Informative) by VLM on Saturday November 22, @03:05PM (1 child)
some of this is somewhat obsolete.
I don't need to log in as root on a container in a cluster somewhere other than for very rare debugging so limiting shell access to the containers to local logins on the cluster seems to work pretty well. If I don't have "root" on the K8S cluster I can't shell into my database container as root, nor would I want to 99% of the time. Mostly to debug semi-automated database upgrade disasters.
Its been awhile since my Ansible systems have needed root access. The newer way has been to ssh in using preshared keys then sudo up to do root things on a remote system.
Any root login at all is anomalous. To say the least of remote root or multiple logins. It does happen for debugging of course, one window watching local logs or monitoring something local and the other messing with things and the remote user switching back and forth. The problem is detecting this will somehow make security theater department even more adversarial, if thats possible.
(Score: 2, Interesting) by Anonymous Coward on Saturday November 22, @11:22PM
You are fixating on a single heuristic and missing the architectural reality by relying on the "Just Disable Root" fallacy. Relying on basic hygiene like disabling remote root logins is not a security strategy. It is merely the baseline configuration. If you assume your cluster is secure because you only use sudo or kubectl with restricted contexts then you are ignoring the vast majority of the attack surface.
The "impossible travel" scenario was a basic example of Identity Threat Detection and Response (ITDR). Real defense requires applying XDR concepts to the Linux environment. This matches what we see in the Windows world with tools like CrowdStrike or Huntress. The goal is not just access control. It is behavioral correlation across the entire kill chain.
An adversary does not need to log in as root to own you.
They exploit a vulnerability in your containerized application running as a service account. They execute code within the context of that pod. They are not logging in via SSH. They are pivoting through an existing session.
This is where you need deep telemetry. You need a system that correlates disparate events into a single narrative. A proper Linux EDR stack connects the dots between a network connection, a process spawn, and a file modification.
You might argue that SELinux solves this but it falls short.
SELinux is a policy enforcement engine. It acts as a static wall. It effectively limits what a process can do based on labels. It creates a blast radius for compromised services.
However, SELinux is not a detection platform because it lacks temporal context. It will block a violation and log an AVC denial. It will not tell you why it happened or what happened five minutes prior. It cannot detect a "living off the land" attack where the adversary uses allowed binaries in a way that technically adheres to policy but violates business logic.
SELinux does not provide the telemetry required for threat hunting. It does not record process genealogy for analysis. It does not snapshot memory when a violation occurs. It simply says "no".
You must implement defense in depth.
You need both. You need the rigid enforcement of MAC policies like SELinux or AppArmor to contain the breach. You also need the observability of an XDR platform to detect the breach in real time.
Focusing on whether root can log in is guarding the front door while leaving the windows open. You need to monitor the behavior inside the house. Modern Linux security uses eBPF to trace syscalls and correlate them with user identity and network activity. This provides the fidelity needed to distinguish between a developer debugging a crash and an adversary establishing persistence.
Stop relying on configuration states. Start monitoring runtime behavior.
(Score: 3, Informative) by chucky on Saturday November 22, @08:31AM
No.
(Score: 0) by Anonymous Coward on Saturday November 22, @10:40AM
Just like i won't use Telegram or any other Russian product or service or believe anything they say.
Why are you promoting a russian product here anyway? What an asshat thing to do.
--------------
Slava Ukraini! Slay the orcs!
(Score: 2, Informative) by Anonymous Coward on Saturday November 22, @01:03PM
These days limiting things from connecting out is a better AV than realtime scanning. You learn what all needs internet and immediately notice something is amiss. Main use of scanning on linux has been for files you download and run in WINE.
Subscription based AV is kind of shit. Trusting it not to spy on you itself is a big hurdle, russian or not.
(Score: 3, Informative) by VLM on Saturday November 22, @02:52PM (1 child)
The most interesting effect of containerization is on security.
Most of my executables are running in a docker container thats wiped and rebuilt "quite often" especially at work for load autoscaling reasons.
Unix-like architectures have an extreme separation between executables and data that you just don't see on Windows architectures where its all just a single insecure filesystem, usually not even backed up.
I was working in a dev container this morning (which doesn't exist anymore) and its interesting to think about even "installing a new language" isn't a thing, or isn't a thing like the old days, you want to mess with Python 3.15 you spin up a dev container and connect with your IDE and don't know the difference. I don't even run the IDE locally, its on a container that is a VPN away from me. Locally I run VPN software and chrome, thats it, nothing else.
This development arch is a PITA for microcontroller / embedded stuff, but it sure is nice generally. You know, if you have a raspi in a project, you can just remote develop on the pi from your IDE that works pretty well. Its the classic embedded like where you'd run platform.io to program a microcontroller thats a PITA. For that I've been running the "good stuff" on a pi connected to the device, then I can mess with it remotely which is also cool (technically you "need" a second pi running something like Node-RED with a relay board in parallel with the pushbuttons to manipulate power, reset, other buttons, but more or less you can oft get away with one pi)
Anyway my point is I don't know how I'd virus scan /bin/ls on a dev container that is susceptible to supply chain or MITM attacks; the whole concept of virus scanning my "system" is weird when most of my system is on a K8S cluster quite a few miles away and the very concept of "the" filesystem is a bit fuzzy
(Score: 0) by Anonymous Coward on Saturday November 22, @03:34PM
We need to lock corporate browsers into a heavily instrumented box, or do away with them
entirely with something that makes everything that code attempts to do VERY visible and
completely isolated.
Nothing they are putting out can be trusted.