ClamAV is a very cool open source anti-virus program that has secretly been powering many anti-virus appliances. Perhaps one of the largest implementers of the ClamAV powered appliance is Barracuda Networks (http://www.barracudanetworks.com/ns/products/spam_overview.php.
While ClamAV certainly has the capability of monitoring and protecting entire corporate networks I don’t have that scale of need. Oh sure theadamsresidence.net provides email access for anyone in the family that wants it and some provide lots of exercise opportunities for the little clam. But that isn’t going to be something to focus on in this particular post.
In this particular post I am going to focus on the use of ClamAV for command line analysis of files and possibly infected thumb drives. I do this so that I can conduct my little Hotel Virus.
At this point you may be wondering why I am not using a standard client installed program like McAfee, AVG or even the online scanning tool Housecall form TrendMicro (http://housecall.trendmicro.com).
Well that is simple: I rarely ever run windows but instead Linux(typically Fedora). Most of the clients that can be installed are Windows based. While I could boot into Windows, install/update the client and then try a scan I also run the risk of infection. I don’t have a license to run Windows in a VM either (It seems to have become a popular choice to use a Windows VM for this type of thing and then destroy the VM after the fact).
So I have installed ClamAV on the server that handles theadamsresidence.net and will instead be transporting an image of the thumb drive to the remote system. I will later implement the ClamAV milter to scan emails for potential virus/malware/spyware.
Getting the drive image to the remote side
To transport the drive I create a PGP/GPG encrypted copy of the drive image. I can then safely transport the file across the network to my remote server. A typical command would look something like this:
gpg -a -r email@example.com -o /tmp/drive.gpg.asc -e /dev/sdb
This will create a GPG/PGP ASCII armoured encrypted copy of the drive that can be safely transported and recovered on the remote side. Why the ASCII armouring? ASCII armour really is nothing more then the use of Base64 encoding of the binary content that was generated by the GPG/PGP algorithm. ASCII transports very well and provides an additional layer to protect against corruption on the remote side.
Once the drive image is created I am going to transport the image to the remote side and decrypt it in one quick move:
cat /tmp/drive.gpg.asc | ssh -XC firstname.lastname@example.org " gpg -d -o /tmp/drive"
This will stream the content through the SSH session and pipe it to the gpg command that will decode it and write it to /tmp/mydrivetransport on the remote host. In order for this to work I generated the GPG/PGP key on the remote host, exported, transferred the key to the local host and then imported and locally signed the key.
Using the drive image on the remote host
Once I have the image on the remote host I have to make it accessible to the ClamAV tool. The best option for this is going to be a mount command with the loop option:
# mount -o loop /tmp/drive /mnt/
While I could have asked ClamAV to dig through the file directly it would not have been able to read the files as it expects. Performing a loop mount makes the file system directly available.
Performing the actual scan
The scan filesystem scan itself is very easy to run on an up to date system using the clamscan command:
# clamscan -r /mnt /mnt/bp.pdf: OK
/mnt/someother.pdf: OK ----------- SCAN SUMMARY ----------- Known viruses: 1095323 Engine version: 0.97.3 Scanned directories: 1 Scanned files: 10 Infected files: 0 Data scanned: 3.85 MB Data read: 1402.10 MB (ratio 0.00:1) Time: 6.344 sec (0 m 6 s)
I elected to use the -r (recursive) option even though there were no subdirectories to worry about. The actual scan only took a few moments before reporting the data. While I suspect it may be much slower with larger data it has worked very well so far. Now that it is done I can safely unmount /mnt and then remove the drive image file or store it for later reference.
I don’t know if these helps anyone out there but then again, maybe it does. ;-)
2011.12.18: Changed filename in gpg/ssh example to shorten example that didn’t render correctly.