ClamAV Software for Unix

The core ClamAV program does not provide real-time scanning by itself, although some varieties/distributions of ClamAV may come with Clamuko which does provide real-time scanning by combining ClamAV with other software.

System Requirements
[#clmunxrm]: Memory requirements for ClamAV/Unix

Forum post on ClamAV requirements shows that clamd grew from November of 2011 through November of 2012, from a bit under 256 MB to 100MB higher (so, about 356MB). (There did not appear to be a single giant jump in memory requirements: that increase of required memory happened over the course of the year.) The poster commented that the server's memory usage had “almost 10% of that to ClamAV. ClamAV is a great tool - perhaps still the best on Linux, but this is simply the price you have to pay to run it.”

(The stats were apparently taken using RRDTool, as the graph cited it was made with Munin. Munim HowToMonitorWindows.)

Memory requirements had been smaller in previous times. ClamAV memory usage, discussion of ClamAV using only 23MB (years ago), forum post indicates ClamAV “uses 150MB in order to load itself.” It appears that there may be some options that have been known to affect memory requirements, by including or excluding various tests. (However, taking up less memory resulted in less checking. People wishing for thorough checks should probably plan to invest the memory to perform those checks.)

Installing the software

Determine if it is pre-installed. (ClamAV Linux packages may provide some information, such as stating “ClamAV has been officially included in the Debian distribution starting from” the Debian release named “Sarge”.)

Add the package. Information about how to do this can be found (for at least some environments) in the section about software installation.) (e.g. for OpenBSD: “ pkg_add -ivv clamav ”.)

Overview of the software
Documentation
Online Docs
The ClamAV Documentation area has latest web manual for the clamav suite. The ClamAV Documentation area also has the latest “man” pages for the clamav suite (presumably designed for view by man, these do have codes in them so may not be as easy to read in a web browser. However, there may be online copies: e.g. e.g. http://linux.die.net/man/8/clamd). The ClamAV documentation area also has documentation in some other file formats.
Freshclam

Freshclam is used to update the definition files. (Newer definition files allow ClamAV to detect new types of malware.) There are options to choose whether freshclam downloads an update immediately and is then done, or whether it acts as a background process (a.k.a. a “daemon”) to continue checking for updates repeatedly over time. The advantage to using Freshclam as a background process, rather than just using cron to update a certain number of times per day according to a strict schedule, is that Freshclam may vary the precise times when the check is done. This variation may help the clamav update site(s), by having loads being more distributed.

To run the command in the background, use: “ freshclam -d ”.

Those who like to use PID files may quickly notice a possible syntax of “ freshclam -dp /var/run/freshclam.pid ”. However, the PID file may also be specified in the configuration file, which is going to need to be customized anyway, so it may be simpler to just specify the PID file there. (That way any pre-created startup scripts won't need any customizing.) Similarly, the number of checks can be specified, e.g. “ freshclam -d -c 1 ” checks once a day. There may be a maximum of “ -c 50 ” which can also be specified as “ --checks=50 ” However, it may be worth mentioning once again, that command line parameter can be specified in the configuration file. So, simply having the script start the program with “freshclam -d” may be fine, since configuration can happen without needing to change that command line.

clamscan
Performs a scan. The advantage to using this clamscan program, instead of using the clamdscan program, is that this clamscan program does not require having clamd be in memory. However, the disavantage is that, for repeated scans, using clamscan may be a slower option than using a combination of “clamd” and “clamdscan”.
clamd

This may go into a directory like /usr/local/sbin rather than the more common /usr/local/bin.

Loads ClamAV into memory. One thing this enables is the clamdscan which is like clamscan (since both programs acomplish the basic action of performing a scan), but clamdscan takes advantage of the copy of ClamAV that is put into memory when clamd is used.

clamdscan
Performs a scan. Unlike clamscan, this does not start a copy of ClamAV but relies on an already started copy called clamd. (If clamd isn't running, clamscan may be used instead.)
[#clmukobn]: clamuko

At least some versions of ClamAV may work with the software called Dazuko in order to provide on-access scanning.

After some information about clamuko was added here, a newer clamd.conf noted, “on-access scanning” ... “is supported via fanotify.” “Clamuko/Dazuko support has been deprecated.”

ClamAV's documentation has been known to say this is for Linux and FreeBSD. This has also been seen in ClamAV's online documentation on Clamuko. Such documentation has been seen at Latest ClamAV documentation: Node 30. In case that moves, check out ClamAV's latest web documentation and search for the “Usage” section, and then the subsection about Clamuko. This documentation also provides details about how to configure the software.

A clamd.conf file may say in comments about clamuko: “WARNING: This is experimental software. It is very likely it will hang up your system!!!” Also, for clamuko to work, “Dazuko (/dev/dazuko) must be configured and running.”

The online documentation does provide a warning about how misuse of Clamuko can interfere with ClamAV mail scanning, resulting in malware becoming allowed/permitted by the mail scanner.

For more details about Dazuko: Dazuko's web page (as pointed to by Wikipedia's page on Dazuko) seems to currently redirect to Dazuko wiki; Wikipedia's page on Dazuko provides a bit of an overview.

clamav-milter

This may go into a directory like /usr/local/sbin rather than the more common /usr/local/bin.

Mail filter for the mailer server called “sendmail”. From the description of its man page: “ Clamav-milter can use load balancing and fault tolerant techniques to connect to more than one” clamav (clamd) “server and seamlessly hot-swap to even the load between different machines and to keep scanning for viruses even when a server goes down.” However, most guides for using clam-av to check spam seem to use amavisd, so this may not be the commonly preferred solution?

Other executables
clamdtop and clamconf show info. sigtool may also come with ClamAV.
rc scripts

e.g. OpenBSD's package comes with /etc/rc.d/clamd and /etc/rc.d/freshclam files may be created when the package is installed.

Handling configuration files and log files (i.e. : Required modification of some key files)
[#clmcfgo]: Early steps to take
[#clmcfplc]: Initial ClamAV configuration file placement

There needs to be a configuration file for the main ClamAV scanner, and one for the updater. These files may not pre-exist in the standard locations where they are looked for, but suitable templates may be hiding, buried in a subdirectory. So start by copying those files where they need to go. e.g., for the updater:

[ ! -f /etc/freshclam.conf ] && sudo cp -p /usr/local/share/examples/clamav/./freshclam.conf /etc/freshclam.conf

For the scanner configuration file, newer versions of the software use a file named clamd.conf so a command like the following may work well:

[ ! -f /etc/clamd.conf ] && sudo cp -p /usr/local/share/examples/clamav/./clamd.conf /etc/.

(Older versions of ClamAV used clamav.conf as the default filename for the configuration file.)

[#clmbkori]: Backing up original ClamAV configuration files

See backing up files if needed. If the cpytobak command is being used, this can be as simple as running:

cpytobak /etc/freshclam.conf /etc/clam*.conf /usr/local/share/examples/clamav/./freshclam.conf /usr/local/share/examples/clamav/./clam*.conf
[#clmavugp]: Identifying user/group info

Now that the files are copied around as needed, identify if there is a group called “_clamav” or perhaps one called “clamav”. This may be done with:

grep -i clam /etc/*passwd* /etc/*group*

If there isn't such a user, make one. (See: creating user accounts.) Although some examples may use a username of “clamav” (without a prepended underscore), other systems use what is probably a better idea of “_clamav”. (The intent of the underscore is to help identify that this is not an account belonging to a standard user. This is simply a convention.) If a username of “clamav” (without a prepended underscore), this convention would recommend taking some time to verify that this is a legitimate account that was created by a trusted administrator for ClamAV.

[#clmdcfed]: Editing the /etc/clamd.conf file
The “Example” line

There may be a line with intentionally invalid syntax which simply says the word “Example”. This helps prevent a user from running the software before configuring the file. Either perform the preferred task which is to comment out that line (by prepending a # character at the beginning of the line), or erase the line completely.

User

Find a line that starts with User. Set it to a special account used for ClamAV. (The default configuration file may not have this set to anything, but perhaps the only considerable reason for that being a sane default is because it would allow ClamAV to work on an operating system that didn't have the specified user. (Perhaps there are some other compatibility considerations if multiple users could run the software, but some/all of those users didn't have access to the one specified user?) However, if a special user does not exist for ClamAV, then creating a user is recommended.

e.g.

User _clamav
Directories

These may be correct by default.

DatabaseDirectory
This is shown as used by A guide called “OpenBSD as a mail server - Content filtering” (section on ClamAV) says to use DatabaseDirectory, set it to /var/db/clamav Example from Membuka wawasan's “Install ClamAV” page shows using /var/db/clamav.
TemporaryDirectory /var/tmp
OpenBSDSupport.org guide called “OpenBSD mail server with spamassassin, amavisd-new, maia mailguard, apache, mysql uses this. The default, from the configuration file's comments, is “system specific (usually /tmp or /var/tmp).” So this probably does not need to be specified.
Socket options
LocalSocket

The default /etc/clamd.conf (as seen, with some modifications, from Membuka wawasan's “Install ClamAV” page) says “Due to security reasons we recommend the local mode.” It appears to be referring to preferring LocalSocket rather than TCPSocket. The default is /tmp/clamd.socket which seems like a fine default. However, note that some guides may make a reference to /tmp/clamd.sock so that may be another widely used name. ClamAV will use whatever filename is specified by this “configuration file” option. Any directions that refer to such a file (such as directions for setting up third party software that interacts with ClamAV) probably just need to match whatever filename is actually going to be used by ClamAV (which will match what this option specifies). It may be customized, as OpenBSDSupport.org guide called “OpenBSD mail server with spamassassin, amavisd-new, maia mailguard, apache, mysql and A guide: “How to install Postfix, Amavisd-new, SpamAssassin, Pyzor, Razor, DCC, and ClamAV on Fedora Core 4 - v2.1.8 (which misspells Razor in the page's TITLE tag) show this using “/tmp/clamd”. (That CSS might be misleading: Perhaps that should be showing as a file rather than a directory.) (The Fedora Core 4 guide just mentioned says the configuration file “shows” that value, which sort of suggests that perhaps that is a default value for some platforms.) A guide called “OpenBSD as a mail server - Content filtering” (section on ClamAV) says to use DatabaseDirectory, have this be /var/clamav/clamd.sock (and then also cleans up a stale socket during system startup, as noted in the later section about cleaning up a socket). Kris/Jolene Nosack's guide for adding ClamAV to an Anti-SPAM Gateway (section on configuring ClamAV) is a page involving the usage of amavisd and it shows that it sets to LocalSocket option (in both /etc/clamav.conf and /etc/freshclam.conf, so the two files have matching values) to a value of “/var/amavisd/clamd.sock”.

A guide: “How to install Postfix, Amavisd-new, SpamAssassin, Pyzor, Razor, DCC, and ClamAV on Fedora Core 4 - v2.1.8 (section on “Issuing Commands to clamd”) has instructions to use a separate piece of software, a packet crafter called socat (which may be a separately downloadable package), to be able to communicate with ClamAV using this socket. (However, the syntax of the telnet command line does not seem to be universally supported. That isn't necessarily an error since the guide was made for a specific operating system (and version).)

e.g.:

LocalSocket /tmp/clamd.socket
Cleaning up a stale socket

There are multiple ways to handle this. A common one seems to be to use a local socket in /tmp/ which will work on systems where /tmp/ is routinely deleted. Another option may be to use the “FixStaleSocket” command: For some reason the default /etc/clamd.conf file may show “FixStaleSocket yes”, however Kris/Jolene Nosack's guide for adding ClamAV to an Anti-SPAM Gateway (section on configuring ClamAV) has a command called “FixStaleSocket” appearing right after the “LocalSocket” line. To do this, simply uncomment the line. (There hasn't yet been any compelling reason found why to not fix this. Perhaps it is problems that might occur if multiple instances of ClamAV are using the same filename for a LocalSocket?)

Another way is to take the approach by A guide called “OpenBSD as a mail server - Content filtering” (section on ClamAV), which does not use either of the above two methods (because for some reason it places the local socket under “/var/clamav/”, a location that it later refers to in /etc/amavisd.conf). The way it deals with things is to delete the socket during system startup. In the operating system startup files, the following was used:

if [ -x /usr/local/sbin/clamd ]; then
echo -n ' clamd'
[ -S /var/clamav/clamd.sock ] && rm -f /var/clamav/clamd.sock
/usr/local/sbin/clamd >/dev/null 2>&1
fi

TCP Sockets
TCPAddr

It is probably most secure for this to not be used, particularly if this is not intentionally trying to be used. Here is where that conclusion comes from: The default /etc/clamd.conf file notes that the ClamAV “daemon” software “can work in local mode, network mode, or both.” “Due to security reasons we recommend the local mode.” Presumably if LocalSocket is used and TCPAddr is used then that means that “both”, not “local mode”, is being used.

Some guides for setting up mail do have this be set: OpenBSDSupport.org guide called “OpenBSD mail server with spamassassin, amavisd-new, maia mailguard, apache, mysql uses this. Membuka wawasan's “Install ClamAV” example shows this being used.

The default /etc/clamd.conf file notes that ClamAV may default to listening on all addresses, which is “probably not wise.” The TCPAddr option may be enabled “to provide some degree of protection from the outside world.” To do this, simply uncomment the following line:

#TCPAddr 127.0.0.1
TCPSocket
This should probably be used if, and only if, TCPAddr is being used. As TCPAddr should typically not be used, there's not likely to be a need to use this. The value in the comments of the default configuration file suggest that the TCP port address of 3310 may be the common default.
Logging
Set LogFile

By default, this is commented out. The path shown in the comment is /var/log/clamd.log. This is a fine idea, but simply requires that the file has permissions so that the user which will be running ClamAV will actually be able to write to the file. (This is used by OpenBSDSupport.org guide called “OpenBSD mail server with spamassassin, amavisd-new, maia mailguard, apache, mysql as well as Kris/Jolene Nosack's guide for adding ClamAV to an Anti-SPAM Gateway (section on configuring ClamAV).)

e.g.:

LogFile /var/log/clamd.log

A FAQ about ClamAV Malware Statistics notes that this log file can help clamd to be useful for submitting statistics to ClamAV. “freshclam will not submit malware detected by clamscan because clamscan does not write to the logfile.”

LogFileMaxSize

e.g.:

LogFileMaxSize 2M
LogTime

Kris/Jolene Nosack's guide for adding ClamAV to an Anti-SPAM Gateway (section on configuring ClamAV) makes a reference to this. Enabling this seems like a decent idea.

e.g.:

LogTime yes
LogVerbose

Kris/Jolene Nosack's guide for adding ClamAV to an Anti-SPAM Gateway (section on configuring ClamAV) makes a reference to this. Enabling this seems like a decent idea.

e.g.:

LogVerbose yes
ExtendedDetectionInfo

Enabling this seems like a decent idea.

e.g.:

ExtendedDetectionInfo yes
PidFile /var/run/clamd.pid

OpenBSDSupport.org guide called “OpenBSD mail server with spamassassin, amavisd-new, maia mailguard, apache, mysql uses this.

Kris/Jolene Nosack's guide for adding ClamAV to an Anti-SPAM Gateway (section on configuring ClamAV) sets this to /var/amavisd/clamd.pid which makes sense for that particular guide (which is using a chroot/jail and is using amavisd software, not just ClamAV). Note that the specified filename should be able to be written when ClamAV is run: Permissions may need to be considered to make this happen. (Perhaps make a /var/run/clamd/ subdirectory with permissions for ClamAV to write to. However, if doing so, find out if /var/run/ is cleared out when the system reboots, then be sure that the directory is made in the operating system's startup procedure after the /var/run/ directory is cleared out but before ClamAV tries to run.)

e.g.:

PidFile /var/run/clamd.pid
Mail-related options

These options may be related to configuring the /etc/clamd.conf file, although they also relate to a setup which is more elaborate than just running ClamAV. Feel free to skip this section if scanning E-Mail isn't something currently being worked on.

StreamMaxLength
The default /etc/clamd.conf says “The value should match your MTA's limit for a maximum attachment size.” OpenBSDSupport.org guide called “OpenBSD mail server with spamassassin, amavisd-new, maia mailguard, apache, mysql uses “StreamMaxLength 20M”.
Leaving ScanMail commented:
The default configuration file shows “#ScanMail yes”. Kris/Jolene Nosack's guide for adding ClamAV to an Anti-SPAM Gateway (section on configuring ClamAV) says “The ClamAV FAQ says this is experimental and should not be used”. (That likely particularly applies when other software performs the same sort of function.)
Excluded

e.g.:

ExcludePath ^/proc/
ExcludePath ^/dev/
ExcludePath ^/srv/virtmach/

(This may benefit from a bit of additional research...) Perhaps /dev/ doesn't need to be excluded to avoid doing something like reading /dev/zero infinitely? (It doesn't seem to be mentioned in the default configuration file.)

... the idea to excluding the virtual machines is that the virtual machines will be running their own checks. As the virtual machine hard drives may have their own signature files, they might be a source of false positives. If the computer running virtual machine software ends up scanning, those files will take a long time, providing extremely negligible benefit if the virtual machine is successfully performing the same sorts of scanning.

Detection
Enabling PUA

e.g.:

DetectPUA yes
Increasing directory recursion

e.g.:

MaxDirectoryRecursion 99
Alerting on problems
VirusEvent logger -st clamdconfig Detection occurred!  %v

That completes the guide for editing the options in the /etc/clamd.conf file.

[#fshclmcf]: The /etc/freshclam.conf file

The other file to edit is “/etc/freshclam.conf”.

OpenBSDSupport.org guide called “OpenBSD mail server with spamassassin, amavisd-new, maia mailguard, apache, mysql shows a way to copy a buried default configuration file, if a configuration file is not in the default location that will be looked at:

[ ! -f /etc/freshclam.conf ] &&
   cp /usr/local/share/examples/clamav/freshclam.conf /etc/

Once such a file exists, customize it.

The “Example” line

There may be a line with intentionally invalid syntax which simply says the word “Example”. This helps prevent a user from running the software before configuring the file. Either perform the preferred task which is to comment out that line (by prepending a # character at the beginning of the line), or erase the line completely.

Other/Misc notes (related to freshclam.conf)
This guide's recommendations

Copy the following lines, and uncomment them, so that they are enabled:

UpdateLogFile /var/log/freshclam.log
LogFileMaxSize 2M
LogTime yes
LogVerbose yes
PidFile /var/run/freshclam.pid
# Multiple database mirrors may be used. ClamAV runs some named after the
# typical country code for the nation (using .us for USA). The default
# config file comments refer to IANA's root domain list at
# http://www.iana.org/cctld/cctld-whois.htm
# The relevant TLD is then embedded into ClamAV sites, as follows:
DatabaseMirror db.us.ipv6.clamav.net
DatabaseMirror db.us.clamav.net
DatabaseMirror database.clamav.net
CompressLocalDatabase yes
# 12 is default; increase to at least 48 if using ClamAV's support for
# Google's SafeBrowsing service.  There might be a maximum of 50.
Checks 12
# This performs an act of testing database, not using test-style databases.
TestDatabases yes
# You can also submit stats by enabling the following line.
SubmitDetectionStats /etc/clamd.conf
# Stats may also be submitted so you may privately view them later.  Since
# they are private, this needs pre-setup.  See comments by DetectionStatsHostID

(The referenced URL http://www.iana.org/cctld/cctld-whois.htm may just redirect to IANA root zones database.)

Alternatively, customizations may be just placed at the top of the file. (The lines should go to the top of the file, so that the default round-robin public server can be listed after any others. The default configuration file simply has the Example line and one DatabaseMirror line which is meant to come after any other/custom DtabaseMirror lines.)

A default file had all lines commented except for Example and DatabaseMirror. The downside to having customizations at the end of the file is that the customized values are then located somewhere other than the comments and example lines, which might cause some confusion by somebody who doesn't check the file's end. Also, placing all customizations at the end will cause the default DatabaseMirror to be used first, instead of being a backup of other customized values.

Some issues may be responded to automatically. At very least, alerts can be easily generated if there is a monitoring system. ClamAV can run a user-defined command. Details would depend entirely on what the desired response is; e.g. for an alerting system, details would depend on what alerting system is implemented. The following shows some examples that may work by placing information in an additional log which isn't specific to ClamAV:

OnErrorExecute logger -st freshclamconfig Error encountered with freshclam. Check log file\(s\) \(e.g. the /var/log/freshclam.log file.\)
OnOutdatedExecute logger -st freshclamconfig The freshclam program notes an outdated version is being used.  \(Check if the new version %v can be installed.\)
OnUpdateExecute logger -st freshclamconfig Database successfully updated. Check log file\(s\) \(e.g. the /var/log/freshclam.log file.\)
NotifyClamd /etc/clamd.log

If a log file was specified, make sure it is usable. e.g.:

sudo touch /var/log/freshclam.log

Handle permissions

grep -i clam /etc/passwd /etc/group

If both files show “_clamav”, then:

sudo chown _clamav:_clamav /var/log/freshclam.log

To read about more possible settings, review the commentary in the default /etc/freshclam.conf file (or a copy of the file which has not had commentary removed). (A copy of the default version of this file may be at /usr/local/share/examples/clamav/freshclam.conf in OpenBSD, although the location likely differs with some other operating systems. Check what files were included in ClamAV's software package.) Also, there may be information available by running “man freshclam.conf ”.

Some other recommendations

Some other guides have provided some recommendations. This guide is not currently making any strong statements about which of these guidelines may be more or less valuable to follow. They are being provided simply as alternatives which may be considered and implemented.

OBSD Support

OpenBSDSupport.org guide called “OpenBSD mail server with spamassassin, amavisd-new, maia mailguard, apache, mysql uses this:

DatabaseDirectory /usr/local/share/clamav
UpdateLogFile /var/log/freshclam.log
LogVerbose
DatabaseOwner _amavisd
NotifyClamd
Kris/Jolene Nosack

Kris/Jolene Nosack's guide for adding ClamAV to an Anti-SPAM Gateway (section on configuring ClamAV) is a site involving the usage of amavisd and it shows that it sets to LocalSocket option (in both /etc/clamav.conf and /etc/freshclam.conf, so the two files have matching values) to a value of “/var/amavisd/clamd.sock”.

Kris/Jolene Nosack's guide for adding ClamAV to an Anti-SPAM Gateway (section on configuring ClamAV) has some recommended lines.

Others
A guide called “OpenBSD as a mail server - Content filtering” (section on ClamAV) has some recommended lines.
[#clmamklg]: Checking permissions for the log file

If the configuration file refers to a log file, that file might need to pre-exist and then have permissions set.

sudo touch /var/log/clamd.log

Press the Enter key a couple of times, so that upcoming file contents can be more easily separated from prior output. Then check for a user or group with the word “clam” or “vscan”.



grep -i clam /etc/passwd /etc/group
grep -i vscan /etc/passwd /etc/group

If both files show “_clamav”, then:

sudo chown _clamav:_clamav /var/log/clamd.log
More configuration steps

A web page (previously at http://polarwave.openbsd101.com/blog/?p=205 but now not there, perhaps under http://polarwave.blogspot.com or http://web.archive.org/web/20100702140452/http://polarwave.openbsd101.com/blog/ ?), called “OpenBSD Newbies blog” by “Denny”: Clamav update from October 31, 2009 says “I want to stress like always that it pays to read documentation. Where you want your TemporaryDirectory, where you want your LocalSocket and DatabaseDirectory and so on. Same goes for your freshclam settings. READ THE DOCS!”

Identify the user for clamav:

grep -i clam /etc/group

(Likely will show “_clamav:*:gid:” where “gid” gid is a number.) (Maybe not if /etc/sgroup is being used?)

Make sure the config files are readable by that user. For example, if the username was _clamav then use:

chown _clamav /etc/clamd.conf /etc/freshclam.conf
Setting permissions
The log file

If /etc/clamd.conf uses a log file (which may be found with ...

grep -i "^LogFile /" /etc/clamd.conf

... then the log file needs to be able to be written to by the user that will be running as ClamAV.

First, check which user ClamAV should run as. “grep -i ^User /etc/clamd.conf ”. If this line does not exist (perhaps because it is commented out), then this step may not be necessary (although it may be wise to follow earlier recommendations/instructions to create a user and uncomment the line and then have a need to follow these steps).

To set these permissions, first make sure that the file exists. (Create the file with an account (which may be limited to being a superuser account) that has access to write to /var/log.)

sudo touch /var/log/clamd.log

Then, once the file exists, set its permissions to use the username found in the configuration file. For example, if the username is _clamav then use:

chown _clamav /var/log/clamd.log
If using a chroot/jail

(This tutorial has not provided details on using a chroot/mail for ClamAV. Doing so may not make much sense if ClamAV is meant to scan files on the entire system, although it may make more sense if ClamAV is part of a mail scanning solution and the entire mail scanning solution is supposed to be part of a chroot/jail.)

Kris/Jolene Nosack's guide for adding ClamAV to an Anti-SPAM Gateway (section on configuring ClamAV) references dealing with the /etc/localtime file (particularly in OpenBSD where this file is a symlink rather than a standard text file) when operating in a chroot/jail. If a chroot/jail is being used, see if /etc/localtime is a symlink. If it is not, copy it to a location in the chroot/jail. If it is, copy the object pointed to by the symlink, and place that copy to a location in the chroot/jail.

Updating the software

This section focuses simply on updating the definitions files. (See the separate section on upgrading the software for details about getting newer versions of the software.)

If this has not yet already been done, backup and then edit the /etc/freshclam.conf file. There are a number of items to customize in the /etc/freshclam.conf file, including specifying the update location.

Run “freshclam -v” followed by “echo $? ”.

That may or may not work well. For instance, if there is an issue with the configuration file, the program may not exit. Hopefully it does work well and the program returns an exit code of zero.

If updating manually worked well, see about keeping the ClamAV databases updated. Running freshclam as a background “daemon” process may be better than using cron (e.g. A guide called “OpenBSD as a mail server - Content filtering” (section on ClamAV) discusses using the crontab) because hopefully freshclam, when run as a background “daemon” process, is intelligent enough to vary the time of its updates so that global usage of the command distributes the load of the servers (whether global or local).

Check to see if the program is currently running in the background. If so, re-running it may cause multiple copies to be run, which is unnecessary. If it is not running, though, then run it.

sudo freshclam -vd

Then, make sure that command (or some suitable equivilent command, such as possibly leaving off the v flag) runs automatically when the system starts up. (Hint: Check for the presense of a /etc/rc.d/freshclam file.)

[#clmascnw]: Performing an instant scan

The log file may need to be pre-created. (See: making ClamAV log file.) Additionally, the following commands may assume that pre-scan preparation has been performed.

[#clmaprsc]: More pre-scan preparation

The following may be needed before the following example commands work well. (This should only need to be done once on a computer.)

sudo mkdir -p /quarantine
sudo touch /var/log/clamscan-report.log
grep -i clam /etc/passwd /etc/group
sudo chown _clamav:_clamav /quarantine

The way generally preferred by the ClamAV software designers is to first make sure that clamd is in memory and then using “clamdscan”. Another option is to use “clamscan”, which is slower. However, using “clamscan” can be simpler (especially for a single-time use), as it does not require clamd to be run ahead of time, and using “clamscan” does not leave ClamAV in memory to speed up subsequent scans. This option is probably only worthwhile on very resource-challenged (memory lacking) machines, or if there is really no belief that a second scan in the foreseeable future is likely. (The second scan might be desirable either at a later hour/date. Or, if there seems to be a fairly high likelihood that problems will be picked up by the first scan, then re-scanning might happen sooner, right after those problems are dealt with.)

Determine what to do, meaning how malware is dealt with. For example, using -i for clamscan informs while both clamscan and clamdscan support using --move=/quarantine to instruct ClamAV to move malicious files to the specified location. Using some options may cause additional types of problems to be detected, such as --detect-pua=yes and --detect-structured (which checks for numbers that appear to be social security numbers or credit card numbers) and --phishing-sigs. There may be more options to help detect more things, so reviewing the ClamAV web page is recommended.

e.g.

time sudo clamd
echo sudo clamd zCONTSCAN /
time sudo clamd zPING

(The time taken to start clamd likely varies between different machines, and has been seen to take approximately two minutes.)

{ time sudo clamdscan -m -l /var/log/clamscan-report.log -v /tmp ; echo Err=$? ; } | sudo -n tee -a /tmp/myscan.log
echo Only do the following if automatic moving is preferred.
{ time sudo clamdscan -m --move=/quarantine -l /var/log/clamscan-report.log -v /tmp ; echo Err=$? ; } | sudo -n tee -a /tmp/myscan.log
echo Check the above line for an Err report to determine results of the scan.

If the results seem desirable, consider scanning / instead of the /tmp/ directory that the examples show.

Attempting to automatically clean-up a threat may or may not be a good idea. For instance, if the file is an executable found in a user's web browser cache, such an attempt may frequently have helpful results. However, attempting to quarantine a virtual machine's hard drive image, just because it may have some suspicious bytes, could theoretically lead to a virtual machine being unable to access its hard drive (which would be very bad if that virtual machine was a critical server that needed to be remaining functional). So, there is no broad, universal advice being given on whether or not to auto-clean.

The new /tmp/myscan.log will likely contain the new contents of the /var/log/clamscan-report.log file, plus show some additional information (as the results from the time command and the echo command).

Enabling real-time scanning
Overview

ClamAV may come bundled with some software called clamuko, which involves integration with some third party software called Dazuko. For an short overview, see clamuko binary.

Additionally, ClamAV is often set up as part of another solution, such as being used to perform scanning of mail (possibly using clam-milter although amavisd seems to be more popular for people to write a guide about), or being combined with an IPS (using snort) to stop malware from completely getting into the network (see OpenBSD Snort-ClamAV (blog entry) or other options compatible with OpenBSD possibly including DansGuardian web filter, snort_inline, snort2pf, here mentions Ossec). Also, Samba-vscan might use ClamAV. (Whether Samba-vscan uses ClamAV has not been confirmed by the author of this guide, at the time of this writing, although it seems likely based on some Clamuko documentation that recommends samba-vscan. This has also been seen in ClamAV's online documentation on Clamuko. Such documentation has been seen at Latest ClamAV documentation: Node 30. In case that moves, check out ClamAV's latest web documentation and search for the “Usage” section, and then the subsection about Clamuko.)

Implementation details
These details are not yet ready.
Reporting issues when problems are noticed

When there are problems, there may be various methods of informing a system administrator about the issue. (This guide does not currently have a fully documented recommended solution. It does, however, have some pointers.)

Using the -i command line parameter to clamscan (not clamdscan) may be a way to list infected files. (That may be useful for a situation to help generate a list of infected files when infected files are unexpected, but are being detected.) Using the logger command may somehow be useful with an alerting system that checks system logs. (For more details on that concept, see reporting events.

E-Mailing (A guide: “How to install Postfix, Amavisd-new, SpamAssassin, Pyzor, Razor, DCC, and ClamAV on Fedora Core 4 - v2.1.8 has a method to inform an E-Mail address. That is done, however, by external software amavisd.)

The default clamd.conf file makes a reference to using a command called /usr/local/bin/send_sms.

Running the software on startup

Checking to see if this was done during installation of ClamAV, or making this happen, depends on having some knowledge of the operating system's startup procedures: section about automatically started files. http://www.hostwurx.com/email-clamav has some info using rc.d.

- Make sure that /var/run/clamd exists and is owned by _clamd. This step also needs to happen as system startup (see below) since most things in /var/run are deleted when the system books. (noted by http://www.teuton.org/~ejm/docs/obsd_sendmail.txt )
Some other misc notes

Here are some older notes that were made when this guide was first being created:

Guide for OpenBSD ClamAV-Milter, SendMail SMTP AUTH, TSL, libmilter (initially written for OpenBSD 3.6; updated to be self-documented to mention that it is “most certaintly” outdated) has info on running clamav-milter. Another resource is: A guide called “OpenBSD as a mail server - Content filtering” (section on ClamAV). Another resource is: A guide called “OpenBSD as a mail server - Content filtering” (section on ClamAV) has code that invovles checking clamd.sock. That should be done if there isn't another method of cleaning up the socket.

http://flakshack.com/anti-spam/wiki/index.php?page=Install+ClamAV has been retired, as noted by Flakshack anti-spam: Flakshack guide to installing ClamAV (with OpenBSD 3.6) (archived by the Wayback Machine @ Archive.org)

http://polarwave.openbsd101.com/blog/?p=205 was also noted as a resource, but does not currently show useful related content.

Notes on upgrading

Upgrading the ClamAV executables may involve downloading the latest source code and compiling it for the specific platform being used. Alternatively, one may wait for a software vendor to release a new version, and then download the pre-packaged version. However, that may work more smoothly in some cases than other. For instance, with OpenBSD, many packages are not updated until the next operating system release (even if the ports are provided sooner). Fortunately, the OpenBSD development team releases a new version of the operating system more often than many others, doing so twice a year. However, relying on that method this does mean that for a period of time up to about six months, during which time the latest anti-virus definition files can generally/always still be updated, but the latest anti-virus programming code may not be.

A guide: “How to install Postfix, Amavisd-new, SpamAssassin, Pyzor, Razor, DCC, and ClamAV on Fedora Core 4 - v2.1.8: section about Installing ClamAV has some installation instructions for using ClamAV by source, in an environment using the Linux kernel.

Kris/Jolene Nosack's guide for adding ClamAV to an Anti-SPAM Gateway: section about configuring OpenBSD to start clamd after a reboot (using instructions that probably pre-dated OpenBSD's support for using /etc/rc.d/)