Are you worried that your Linux computer may be infected with malware? Have you ever checked? While Linux systems tend to be less susceptible to malware than Windows, they can still be infected. Many times they’re less obviously compromised, too.
There are a handful of excellent open-source tools to help you check if your Linux system has been the victim of malware. While no software is perfect, these three have a solid reputation and can be trusted to find most known threats.
1. ClamAV
ClamAV is a standard anti-virus and will probably be the most familiar to you. There is actually a Windows version of ClamAV too.
Install ClamAV and ClamTK
ClamAV and its graphical front end are packaged separately. That’s because ClamAV can be run from the command line without the GUI, if you choose. Even still, the graphical interface ClamTK is easier for most people. The following is how to install it.
For Debian and Ubuntu-based distro:
sudo apt install clamav clamtkYou can also find clamav and clamtk in your distro’s package manager if you are not using Ubuntu based distro.
After both programs are installed, you have to update its virus database. Unlike everything else with ClamAV, that has to be done as root or with sudo.
sudo freshclamThere’s a chance that freshclam is being run as a daemon. To run it manually, stop the daemon with Systemd. Then, you can run it normally.
sudo systemctl stop clamav-freshclamIt’ll take some time, so just let ClamAV take care of things.
Run Your Scan
Before you run your scan, click the “Settings” button and check off “Scan files beginning with a dot,” “Scan files larger than 20 MB,” and “Scan directories recursively.”
Go back to the main menu and click “Scan A Directory.” Select the directory that you want to check. If you want to scan the whole computer, select “Filesystem.” You may need to rerun ClamTK from the command line with sudo in order for that to work.
After the scan completes, ClamTK will present you with any discovered threats and allow you to choose what to do with them. Deleting them is obviously best, but may destabilize the system. This comes down to a judgement call for you.
2. Chkrootkit
The next scan to install is Chkrootkit. It scans for a type of malware specific to Unix-like systems like Linux and Mac – the rootkit. As the name suggests, the aim of rootkits is to gain root access on the target system.
Chkrootkit scans system files for signs of malicious alterations and checks them against a database of known rootkits.
Chkrootkit is available in most distribution repositories. Install it with your package manager.
sudo apt install chkrootkitCheck For Rootkits
This one is very easy to run. Just run the command as root or with sudo.
sudo chkrootkitIt’ll run down a list of potential rootkits very quickly. It might pause for a while on some while it scans through files. You should see “nothing found” or “not infected” next to each one.
The program doesn’t give a final report when it finishes, so go back through and manually check that no results turned up.
You can also pipe the program into grep and look for INFECTED, but that won’t catch everything.
Known False Positives
There’s a strange bug with Chkrootkit that reports a false positive for Linux/Ebury – Operation Windigo. This is a long-known bug caused by the introduction of a -G flag into SSH. There are a couple of manual tests you can run to verify that it is a false positive.
First, run the following as root.
find /lib* -type f -name libns2.soIt should turn up nothing. Next, check that the malware isn’t using a Unix socket.
netstat -nap | grep "@/proc/udevd"If neither command turns up any results, the system is clean.
There also appears to be a fairly new false positive for tcpd on Ubuntu. If it does return a positive result on your system, investigate further, but be aware that the result could be incorrect.
You also may encounter entries for wted. Those can be caused by corruption or logging errors on system crashes. Use last to check to see if the times line up with reboots or crashes. In those cases the results were probably caused by those events and not malicious activity.
3. Rkhunter
Rkhunter is yet another tool for searching out rookits. It’s good to run both Chkrootkit on your system to ensure that nothing slipped through the cracks and to verify false positives.
Again, this one should be in your distribution’s repositories.
sudo apt install rkhunterRun Your Scan
First, update rkhunter’s database.
sudo rkhunter --update
Then, run your scan.
sudo rkhunter --checkThe program will stop after every section. You will probably see some warnings. Many arise because of sub-optimal configurations. When the scan finishes, it’ll tell you to take a look at its full activity log at /var/log/rkhunter.log. You can see the reason for every warning there.
It also gives you a complete summary of its scan results.
Closing Thoughts
Hopefully, your system turned up clean. Be careful and verify any results you receive before doing anything drastic.
If something is legitimately wrong, weigh your options. If you have a rootkit, back up your files and format that drive. There’s really no other way.
Keep these programs updated and scan regularly. Security is always evolving and threats come and go. It’s up to you to stay up to date and vigilant.
12 comments
ClamAv scan of the entire system takes at least couple of hours.
“If you have a rootkit, back up your files and format that drive.”
If you backup your files, wouldn’t you also be backing up the rootkit making the backup useless?
> If you backup your files, wouldn’t you also be backing up the rootkit making the backup useless?
It would just be the data on a non-bootable drive. Unless I’m missing something here. Maybe for added protection, the external drive is fat32 or ntfs – vs – the system’s ext3/4 or other.
Backing up your personal files means that nothing of any great importance will be lost – if you have to reinstall completely. Of course you may well have separated your personal files already, that would be the better solution.
Backing up to an NTFS partition would avoid the ‘permissions’ problems if the worst came to the worst where you had to reinstall and restore files to your new ‘home’ directory.
You are making a big assumption that the rootkit is isolated only to the ‘/’ partition or ‘root’ id. How do you know that a copy of the malware has not been stored somewhere among your personal files, regardless of whether you use a separate ‘/home’ partition or not? If such is the case, doing the distro install from scratch and then restoring ‘/home’ from a backup is pointless because the rootkit will re-install itself as soon as the restore is finished. The way I see it, the rootkit must be thoroughly removed from the storage device before even thinking of doing any kind of backup. After all, you would not do a backup if you suspected that there were viruses among the files, would you?
Of course you are right. Truly the only way is to scrap the storage media along with the system and start afresh. Forget about protection, just scrap the lot and start afresh. Why didn’t I think of that?
Back up personal files to an external USB-connected drive. Then mount as read-only on an uninfected system, and run your malware scanners on the files.
It really all depends on which rootkit it is and what’s actually affected. Most rootkits don’t care about your documents, pictures, music collection or anything along those lines.
Attackers are looking for known predictable targets. It’s the only way they can be certain that their malware will function properly. Plus, those kind of files don’t really do much for an attacker in most situations. They’re looking to escalate privileges, gain root, and control the machine for whatever nefarious purpose. Infecting some memo you wrote won’t exactly achieve that.
So, I suggested backing up files(meaning files of that sort) because the chances of them being the target of a rootkit are slim. However, you should always research the results that a malware scan gives you, and if that research suggests that those files are compromised, you’re only option is to lose them or back them up to an external medium and scan it with a live distro.
I hope that clarifies things.
Above you have
sudo apt install chkrookit
Should be
sudo apt install chkrootkit
You should mention Lynis as well.
Good point. Lynis was developed by the same guy who wrote rkhunter.
i thought they mainly affected securityvulnerable things that could be exploited to gain root such as vim or useradd maybe(im really just guessing but u get the idea) like making copys of these programs with modified code or something and hiding the binarys and what not or is that something else? i have used linux for a long time, tons of gentoo experience but i never really considered actually learning the shit that would actually land me a job working with linux idk any suggestions? ive been thinking of doing just that, i mean kernel patch? np.. netgear wifi routers in 2017 still dont understand that theres more to life than windows aparently, and i do a lot of compiling even on debian from source just so i learn things occasionally by breaking things, im completely self taught, bash proficient and pretty good knowledge of how the system is composed since ive compiled prolly a couple hundred of them but also i want to learn the security stuff, not just using kali in fact i would never, anyone can run a pre made program id rather learn the systems and write my own could use some advice where the best source of knowledge is, oh and hosting a site using apache too and a mail server all cmd line manually done if possible, the only real way imo is the cmd line
Hello,
Just started using Linux (Lubuntu 17.1) . Installed chkrootkit and id a full system scan which took over two hours. I am trying to get some insight as to what these results mean. I just read above that the ‘tcpd’ may be a false positive. What of the suspicious files and directories?
scan results:
Checking `tcpd’… INFECTED
Searching for suspicious files and dirs, it may take a while… The
following suspicious files and directories were found:
/lib/modules/4.13.0-21-generic/vdso/.build-id
/lib/modules/4.13.0-38-generic/vdso/.build-id
/lib/modules/4.13.0-21-generic/vdso/.build-id
/lib/modules/4.13.0-38-generic/vdso/.build-id
I have no clue what these are and before I go further, I am hoping someone can give me a heads up as to any potential problems and solutions, should these results indicate same.
Thank you in advance for any feedback.
Sincerely,Rocky