This article tries to explain, using my own experience of server management, how to scan a Linux server for viruses and malware.
You are probably here because you have something on your server already, very often pushing out spam emails to people via php files. Or maybe you have fallen victim to the Hacking Holy Grail – the attacker now has root access to your server. Let’s stop that now, eh?
This tutorial has screenshots from a CentOS server and this is what I used to create this guide. Your server may well be different but the principles I use are the same, you may have some detail changes to make regarding file paths. If you don’t understand anything drop me a comment or use a search engine to find your answer quickly.
Let’s start by running a virus scan with ClamAV, a free and useful antivirus. Presuming that it is not installed we would need to do this (skip to your OS below or jump to updating definitions if it is already installed):
Installing ClamAV on CentOS 5
Install EPEL5 https://fedoraproject.org/wiki/EPEL/FAQ#howtouse
Now we can install ClamAV using the yum package manager
Now turn on and start the clamd daemon
Installing ClamAV on CentOS 6
Install EPEL6 https://fedoraproject.org/wiki/EPEL/FAQ#howtouse
Install ClamAV using the yum package manager
Now turn on and start the clamd daemon
Installing ClamAV on Ubuntu/Debian/Mint
Install ClamAV using the apt-get package manager
The latest installer automatically creates default configuration files and launches the freshclam and clamd daemons. You don’t have to do anything else here which is a nice touch.
Righto, now let’s update the virus definitions…
Updating ClamAV virus definitions
For the sake of brevity, I’m presuming CentOS 6 from now on but it will be the same or similar for most Linux derivatives.
In /usr/local/cpanel/3rdparty/bin/ we can run this to get the latest definitions:
And now we can do a full scan with a full report sent to a log file of our choice:
/usr/local/cpanel/3rdparty/bin/clamscan -ri -l /path/to/log.file -r /path/to/be/scannned
Note: The tilde character denotes the home directory for that user and the wildcard (asterisk) denotes all users in the home directory. If you want to scan a single user’s home directory then simply put their name where the wildcard is.
In the files above we use some switches.
- -r means that we recurse the subdirectories
- –i means Clamscan will only list infected files (chained together with recurse above we get -ri)
- -l means that Clamscan will log to the path you choose after it
For more help, run /usr/local/cpanel/3rdparty/bin/clamscan –help
Now it’s coffee time as your server is scanned over by ClamAV using the latest definitions. When it is finished you will see your bash prompt again. Ideally, you see that Clam reports no infections like this:
While it’s running, try to have a look online for what may have caused the infection and see if it ties up with your Clam results. Very often we see that WordPress plugins have caused the issue. Why them? Well, think about it:
WordPress is the most popular Content Management System out there
- It’s used worldwide
- It’s often installed at the click of a button using tools such as Softaculous, so it’s dead easy to install
- It’s free, ‘Open Source’ software so attackers know the code inside out (well GNU GPL actually)
- There are a huge amount of free plugins available from developers around the world, many who have a less-than-basic grasp of how to code securely. Even the good ones get caught out!
Now my third point above is not really fair. It kind of insinuates that Open Source software is more unreliable in the security stakes. Quite the opposite in fact, vulnerabilities get plugged very quickly if there is an active community of developers. However, the sheer ubiquity of WordPress leads to it being a target in much the same way that Microsoft Windows is. The gains for an attack on WordPress are much more than one for Drupal (for example) purely because of the user base.
Even if a vulnerability is plugged with an update pretty fast, it still relies on the user being aware of the problem, downloading the update and applying it BEFORE someone exploits it. To this end, a daily Clam scan is not a bad idea unless your server has lots of files on it or not many resources available to run the scan in a timely fashion.
Moving on from this virus scan, I would suggest that we look at what email your server is sending out. I detail it in this article here:
Find what emails are being sent from a Linux server