Testing the ClamAV installation

My previous post covered all necessary steps for successful install of ClamAV as the Windows service. However, we didn’t covered the test procedure. Sure, our services are happily running, yet we don’t know if we can use ClamD to scan suspicious files.

We’re using the same server and the same installation from the last time. We will continue this demonstration with the previously installed solution and running services. As this server is isolated, we will use the same yet bit older signatures database. That will produce the warning message during the ClamAV’s start-up.

To test our anti-virus solution, we will use the EICAR standard virus test sample. This is not the actual virus and it’s safe to be used for tests of any anti-virus solution. Every AV solution in the World must identify this file as virus.

As our demo server is based on Microsoft Windows 2019 Standard server, it has Windows Defender installed and running. Therefore, I excluded the folder with EICAR sample (yes, Defender will jump on it immediately) and also the ClamAV database folder.

Bear in mind that signatures may contain the characteristic sequence (the signature) of the real viruses and that can trigger other real-time AV solution to react on such file as malicious.

As you can see on the Web page, there are 4 variants of the same test sample and we will use them all. That means that our test should return 4 of 4 infected files.

Checking the listening port

Now, when everything is in place, we can start the test procedure. Let’s check the listening port. We will use the netstat command and filter the output with the find command.

netstat –an | find “:3310”

As you can see, the clamd service is running and listening on the IP address 127.0.0.1 (i.e. localhost) and the standard TCP port 3310. Additionally, it uses both IPv4 (127.0.0.1) and IPv6 (::1) stacks.

If ClamD isn’t on this port and we’re on the same machine, we can open the clamd.conf file and check for the associated port. This port is designated with the parameter TCPSocket. Other way is to find the process in memory and its PID number, then to filter the output of the netstat command by that PID (we can see PIDs with the –o option).

Running clamscan to test the database

The next test will actually test the database not clamd itself. The command line on-demand tool is named clamscan. It can be used to scan on-demand any file or folder.

When we run clamscan it will by default scan the current folder. As we need to scan one specific folder, we will add the full path to it.

clamscan c:\Temp\eicar

There is a plethora of options for this tool and you can see them all with the --help option. We can specify what we want to scan, which type of files, should we delete or move that file in quarantine, etc.

Nonetheless, we need to test only loading of the database and capability to identify the test virus. Therefore, we will only scan this one folder and we will not touch it in any other way.

As you can see from the screenshot above, we have the warning that our database is older than 7 days. The database is updating a few time during the day and sometimes even 7 days can be too long. In this specific case, we will ignore this warning, yet you should take it seriously on the production system.

When you start clamscan, just sit back and relax. Maybe you can use the cup of coffee too, as this process will take a while.

We can see that clamscan needs to load the database in the memory and that process will take some time. How long it takes still depends on many factors, like amount of free RAM (you will need more than 1GB of free RAM to load the whole database), the disk type and speed, current CPU load, etc.

In our case, as this is empty demo VM, running from M.2 drive, the whole process lasted slightly more than 53 seconds. Of course, all 4 samples are correctly identified (4 of 4 ratio). Therefore, we can conclude that our database can be loaded and used for the real scanning process.

Even better, if you place ClamAV on your USB drive, you can use it in such on-demand mode to scan any computer for suspicious files and potential viruses.

Running clamdscan to test the service

This test will use the clamdscan command line tool which is actually the client (front-end) for the clamd service. This tool will not load any signature, yet it will send every file to the designated Clam AV server for the further processing. It will react on every scanned file respectively to the received answer from the selected ClamAV server.

Although there are a lot of options (you can see them with the --help option), we will use it in the simplest form

clamdscan c:\Temp\eicar

This will instruct clamdscan to scan all files in the named folder.

As you can see, there are no messages related to the signatures database, no warning about older version or anything else. Only 4 lines indicating that every sample there is identified as a virus.

In addition, the complete scan time was really in split second! Indeed, all 4 files are very small (the EICAR file is only 68 bytes long) and the whole operation was quick. Nevertheless, even with the real viruses this process will be fast.

Bear in mind that clamdscan will not occupy to much RAM and it can be used even on the low power machines. The whole load of handling signatures and scanning files is on the server side, as we can see from the screenshot of the clamd service’s log.

Using clamdscan with the remote clamd service

As you remember from the other article, we installed the ClamD service with mostly default options. That means that service will listen on the IP address 127.0.0.1 and the TCP port 3310. Although there’s no such place like 127.0.0.1, such server isn’t too much useful except for the local operations.

I changed the parameter named TCPAddr. More precisely, I just commented it in the clamd.conf file and restarted the service. By default, if this parameter isn’t configured, ClamD will listen on all external IP addresses. As 127.0.0.1 is actually the loopback or localhost address, the service will not listen on this IP anymore.

As you can see, the service is listening on any address – 0.0.0.0. I repeated the previous clamdscan command, yet this time we faced the error. Unfortunately, clamdscan isn’t too informative in the similar situations, as it’s only the frontend to the scan engine.

The problem is that clamdscan will try (by default) to connect to the service listening on 127.0.0.1:3310 (i.e. on the loopback address and default port). Still, we need to connect to the service listening on the other address and port.

The answer is very simple – we will create the clamdscan.conf file and instruct clamdscan to use it! We need to specify only two parameters – TCPAddr and TCPSocket.

I added the IP address of the server (in my case, 192.168.17.29) and the port is still 3310. This file is placed in the same folder with clamdscan.exe program.

I ran clamdscan referencing that config file

clamdscan --config-file=.\clamdscan.conf c:\Temp\eicar

As expected, this time it established the connection to the “remote” server and performed the test in the correct way.

Now, when all test passed successfully, we can say that our ClamAV instance was installed correctly and it can be used in the production. In case that you face any problem during those tests, check again all commands you typed. In addition, check the config files for both freshclam and clamd services to find out what is configured there.

Check every step one by one. The short list of steps used in this process is:

• check if both services are running on the server
• check the clamd listening port (commonly 3310) and IP address (by default – 127.0.0.1)
• place the EICAR AV test file somewhere on the local disk (there are 4 variants provided on the site)
• use the clamscan command line scanner to check the database and to identify all samples
• use the clamdscan frontend tool to check the clamd service
• in case that clamd service listen on other IP address or port than default ones, make the clamdscan.conf file and instruct clamdscan to use it

In some specific cases, we can also use the different location for the database while scanning with clamscan. Even more, you can also increase the output to the debug level and more technical details will be print.

Stay tuned.