The belief that Linux systems cannot get malware is one of the most dangerous misconceptions in system administration. Linux servers are actively, constantly targeted by automated attacks. The majority of cryptocurrency miners, web shells, and botnet implants running today are on Linux machines — because that is where most of the world’s internet infrastructure runs.

The threat landscape for Linux

Linux desktop systems face fewer threats than Windows desktops because most malware targets the larger Windows user base. But Linux servers face a very different reality:

Internet-facing Linux servers get probed within minutes of going online.
SSH brute-force bots run 24/7 against every IP on port 22.
Unpatched web applications are scanned and exploited continuously.

Common Linux malware categories:

Type	What it does	How it gets in
Crypto miner	Steals CPU for mining Monero/etc	Web app vuln, weak SSH
Web shell	PHP/Python backdoor in web app	Vulnerable web application
SSH backdoor	Adds attacker key to authorized_keys	Brute force, web shell
Botnet client	DDoS, spam relay	Weak credentials
Rootkit	Hides other malware	Post-exploitation
Ransomware	Encrypts files, demands payment	Web app vuln, SSH

Signs of compromise

If you see any of these, investigate immediately:

# High CPU from unknown processes
ps aux | sort -k3 -rn | head -20
top                                  # look for persistent high-CPU processes

# Processes with suspicious names
ps aux | grep -E "kworker|systemd-[0-9]|java|python" | grep -v grep
# Legitimate kworker processes exist, but miners often use similar names

# Unexpected network connections
ss -tnp
netstat -tnp                         # outbound connections to mining pools

# Unusual listening ports
ss -tlnp

# New cron jobs
crontab -l
sudo crontab -l
ls -la /etc/cron* /var/spool/cron/crontabs/

# Unfamiliar SSH keys
cat /root/.ssh/authorized_keys
find /home -name authorized_keys -exec cat {} \;

# Recently modified system binaries
sudo find /usr/bin /usr/sbin /bin /sbin -newer /var/lib/dpkg/info -type f 2>/dev/null

# Unusual network traffic
sudo tcpdump -i eth0 -n | head -50
sudo iftop                           # requires iftop installed

How attackers get in

Understanding the attack vector helps you close it:

1. Weak or reused SSH passwords

# Check for failed SSH logins
sudo journalctl -u sshd | grep "Failed password" | \
  awk '{print $NF}' | sort | uniq -c | sort -rn | head

# Fix: disable password auth, use keys only
# /etc/ssh/sshd_config:  PasswordAuthentication no

2. Unpatched web applications

# Check for outdated WordPress
wp core check-update --path=/var/www/html   # requires wp-cli

# Check for PHP version (older versions have known vulns)
php --version

# Web application firewalls help
sudo apt install libapache2-mod-security2   # ModSecurity for Apache

3. Unpatched server software

# Check for packages with security updates
sudo apt list --upgradable 2>/dev/null | grep security
sudo dnf check-update --security

# Apply security updates now
sudo apt-get upgrade -y
sudo dnf upgrade --security -y

4. Exposed services with weak credentials

# Look for services that should not be internet-facing
ss -tlnp
# Database (3306), Redis (6379), MongoDB (27017) should NOT be on 0.0.0.0

# Redis with no auth is frequently exploited
redis-cli ping                       # if this works without auth, you are at risk

Rootkit detection

# Install rkhunter
sudo apt install rkhunter
sudo dnf install rkhunter

# Update the database of known-good file hashes
sudo rkhunter --update
sudo rkhunter --propupd           # record current state as baseline

# Run a check
sudo rkhunter --check

# Run without prompts (for cron)
sudo rkhunter --check --skip-keypress

# Install chkrootkit (second opinion)
sudo apt install chkrootkit

# Run chkrootkit
sudo chkrootkit

Important: rootkit detection tools are most reliable when run from a trusted live environment (bootable USB with a known-good OS) or when you compare against a baseline taken before the compromise. A running kernel rootkit can intercept and fake the results of tools run on the compromised system.

ClamAV: scanning for known malware

ClamAV is the standard open-source antivirus for Linux. Its main use on servers is scanning web application directories for web shells and malicious uploads.

# Install ClamAV
sudo apt install clamav clamav-daemon
sudo dnf install clamav clamd

# Update virus signatures
sudo freshclam

# Scan a directory
sudo clamscan -r /var/www/html/
sudo clamscan -r --bell --remove /var/www/html/uploads/   # ring bell, remove on find

# Scan and report only infections
sudo clamscan -r --infected /var/www/html/

# Run as a background daemon for real-time scanning
sudo systemctl enable --now clamav-daemon

File integrity monitoring

AIDE (Advanced Intrusion Detection Environment) creates a database of file checksums and attributes so you can detect changes:

# Install
sudo apt install aide

# Initialize the database (do this on a fresh, uncompromised system)
sudo aideinit
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Check for changes
sudo aide --check

# Run weekly via cron
echo "0 3 * * 0 root /usr/bin/aide --check 2>&1 | /usr/bin/mail -s 'AIDE report' admin@example.com" | \
  sudo tee /etc/cron.d/aide

Audit log monitoring

# Enable the audit daemon
sudo apt install auditd
sudo systemctl enable --now auditd

# Watch for privilege escalation
sudo auditctl -w /etc/sudoers -p wa -k sudoers
sudo auditctl -w /etc/passwd -p wa -k passwd-changes

# Watch for execution of commands by suspicious users
sudo auditctl -w /usr/bin -p x -k exec-monitor

# View audit events
sudo ausearch -k sudoers -ts recent
sudo ausearch -k passwd-changes -ts recent

# Review auth log for suspicious logins
sudo last | head -30
sudo lastb | head -30              # failed logins

If you suspect a compromise

# Do NOT reboot immediately -- memory forensics is lost on reboot
# But do isolate the machine first if possible

# 1. Take a snapshot of running processes and connections
ps aux > /tmp/processes-snapshot.txt
ss -tnp > /tmp/connections-snapshot.txt
crontab -l > /tmp/crontab-snapshot.txt

# 2. Preserve logs
sudo cp /var/log/auth.log /tmp/auth-$(date +%F).log
sudo journalctl --since "72 hours ago" > /tmp/journal-$(date +%F).log

# 3. Check for recently modified files
sudo find / -not \( -path /proc -prune \) -not \( -path /sys -prune \) \
  -newer /var/lib/dpkg/info -type f 2>/dev/null | \
  grep -v "\.pyc\|/var/cache\|/tmp" > /tmp/recent-files.txt

# 4. Check for suspicious processes/files
sudo rkhunter --check --skip-keypress
sudo chkrootkit

# 5. Decision: clean or rebuild?
# For most compromises, rebuilding the server from scratch
# is faster and more reliable than attempting to clean a rootkit.

Preventive measures summary

# Keep software updated (closes the vulnerabilities attackers exploit)
sudo apt-get upgrade -y
sudo dnf upgrade -y

# Disable password SSH (stops brute force)
# /etc/ssh/sshd_config: PasswordAuthentication no

# Keep only necessary services running
sudo systemctl disable --now <unneeded-service>

# Bind services to loopback that do not need to be public
# Redis: bind 127.0.0.1 in redis.conf
# MySQL: bind-address = 127.0.0.1 in my.cnf

# Enable a firewall with default-deny
sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

# Set up fail2ban for SSH
sudo apt install fail2ban

# Run integrity checks
sudo apt install aide rkhunter chkrootkit
sudo rkhunter --propupd    # take baseline
sudo aideinit              # take baseline

Frequently Asked Questions

Can Linux get viruses and malware?

Yes. Linux is actively targeted by malware, particularly on servers. Common Linux malware includes cryptocurrency miners (which hijack your CPU to mine crypto for attackers), botnets (which use your server to send spam or participate in DDoS attacks), web shells (malicious PHP or Python scripts installed in a compromised web application that give attackers a persistent backdoor), rootkits (which hide the attacker’s presence by modifying kernel modules or system utilities), and ransomware (though less common on Linux than Windows). Linux desktop systems are less commonly targeted than servers but are not immune.

Why does the myth persist that Linux is immune to malware?

The myth has several origins. Linux does have a better security architecture than older Windows versions: a strong separation between users and root, no autorun for USB drives by default, no macro execution in documents by default, and a permission model that limits what programs can do. Linux also has a smaller desktop user base, making it a less attractive target for mass-market malware campaigns. But none of this applies to Linux servers, which are heavily targeted. The myth persists because Linux desktop users have historically had good outcomes without antivirus software, which people generalise incorrectly to “Linux cannot get malware.”

What does real Linux malware look like?

Most Linux malware arrives through vulnerable web applications (unpatched WordPress, exposed admin panels, SQL injection), weak or reused SSH passwords, or publicly disclosed vulnerabilities in server software that was not promptly patched. Once in, attackers typically install a cryptocurrency miner (run as a cron job or systemd service), a rootkit to hide their presence, and a persistent backdoor (SSH key in authorized_keys, or a web shell). Warning signs include: unexpected spikes in CPU usage, processes with names like kworker or systemd that do not appear in ps, new entries in crontab or /etc/cron.d/, and unfamiliar SSH keys in authorized_keys.

Should I run antivirus software on Linux?

For servers, the main use case for antivirus on Linux is scanning files that will be served to Windows users (e.g., a mail server or file server). ClamAV is the standard free option. For detecting Linux-specific malware, traditional antivirus is less useful than behavioural tools. More effective approaches are: keeping software updated (patching eliminates the vulnerability attackers use to get in), using a Web Application Firewall for web applications, running integrity monitoring tools like AIDE or Tripwire, monitoring logs for anomalies, and using rkhunter or chkrootkit to detect rootkits. For Linux desktops used personally, antivirus is generally unnecessary if you follow good security practices.

What is a rootkit and how do I detect one?

A rootkit is malware that hides its presence from the system administrator by modifying kernel modules, system binaries, or the /proc filesystem to conceal processes, files, and network connections. A userspace rootkit replaces system utilities (ls, ps, netstat) with modified versions that hide specific entries. A kernel rootkit (LKM rootkit) loads as a kernel module and intercepts system calls. Detection tools include rkhunter (checks system binaries against known-good hashes, scans for suspicious files and configuration) and chkrootkit (checks for signatures of known rootkits). Run these from a live boot or trusted media for reliable results — a running rootkit can fool tools run on the compromised system.

How do I scan a Linux system for malware?

A multi-tool approach works best. Run rkhunter —check to scan for rootkits and backdoors. Run chkrootkit for a second opinion on known rootkit signatures. Use ClamAV (clamscan -r /home) to scan for known malware including web shells and Windows malware that may be hosted on your server. Check for crypto miners with ps aux | sort -k3 -rn (high CPU processes) and crontab -l plus ls /etc/cron* for unexpected scheduled tasks. Audit /root/.ssh/authorized_keys and /home/*/.ssh/authorized_keys for unrecognised keys. Check for recently modified binaries: find /usr/bin /usr/sbin /bin /sbin -newer /tmp/ref -type f (where /tmp/ref was touched before the suspected compromise).