[clamav-users] Questions about ClamAV installers
clamav at jubileegroup.co.uk
Wed Aug 28 16:40:15 EDT 2019
On Wed, 28 Aug 2019, Scott A. Wozny via clamav-users wrote:
> I’m looking at installing Clam on my CentOS 7 servers ...
Sorry, but I have to ask :)
> sites offering install tutorials recommend installing
Hmmmm. Sites with tutorials. I guess I avoid them.
> clamav-server clamav-data clamav-update clamav-filesystem clamav
> clamav-scanner-systemd clamav-devel clamav-lib AND
Those are 'packages' from the OS distributions, created and maintained
by the OS distribution maintainers. The ClamAV source (which you'd
get e.g. from the clamav.net site) is a completely different animal.
It's like this:
There are (approximately) two approaches to installing software on a
Linux (or similar Unix-like) box.
You can get the source of the software and build it on the box, using
(and here I abridge, paraphrase and bowdlerize mercilessly) some set
of commands such as, for example, say, perhaps, the ClamAV software:
tar czvf clamav-0.101.4.tar.gz
Now you have ClamAV installed into the places in your system that the
people who produced it decided that it would go when they made that
tarball. You can now delete ~/src/clamav-0.101.4/ and everything in
there, you're done with it. Really.
The result of all this might not be what you want, so you can twiddle
things to put things elsewhere, but don't get involved in that yet.
It also might not work, because there might be things _not_ on your
machine that are needed in order to compile this particular software.
Or indeed _any_ software. You won't get very far without a compiler
for example, and some distributions don't ship with one as standard.
You can install a 'package' from the people who produce your 'flavour'
of Linux, or other OS. You can simply say
apt-get install clamav
and the package tool (in my example APT, but then this is a Debian
box) will not only install clamav (whatever that is) but it will also
install everything that clamav package needs if it isn't already on
the system. Compilers and all the gubbins that goes with them tend to
be BIG. You most likely won't need one if you do it this way because
you'll be installing *binaries* (that have already been compiled for
your system's architecture - i686, AMD64, etc.) from the packages.
This is a lot simpler, and generally recommended if you aren't VERY
familiar with your system. The main trouble is that documentation as
you seem to have discovered is sometimes a bit sparse, so you don't
always know which packages you need in order to do what you want,
always assuming that you know what you want to do in the first place.
Another problem is that OS package maintainers often do strange things
with the packages before they ship them out. They'll almost always
put everything in different locations, so you can have (at least) two
versions of the software on the system: the OS packaged version and
the built from source ('upstream') version. But dont do that unless
you really know what you're doing.
Another problem is that the OS packages are often out of date. For
something like ClamAV, I'd almost always compile from source.
Oh, and Macs are a bit different, but they're basically BSD boxes.
For some reason whenever I play with one, it always seems like I'm
blindfolded, with my hands tied behind my back.
> the official documentation is just to install ClamAV.
The OS distribution packages on the one hand, and ClamAV from the
Sourcefire/Talos/Cisco emporium on the other hand bear no resemblance
to each other, except that the same sources, more or less, were used
to create both.
> So, is there a list of the purpose of each of these packages somewhere?
That's up to the OS people who packaged it.
> ... looks like ClamAV contains all the major pieces (clamav,
> clamav-filesystem, clamav-lib, clamav-update, libtool-ltdl and
> pcre2) EXCEPT for clamd.
It's not like that. If you download for example clamav-0.101.4.tar.gz
from the clamav.net site you get everything you need to get _from_the_
_ClamAV_people_ in the one tarball. But you'll need other stuff too.
You won't get a compiler of course, and you won't get a bunch of 'C'
header files and libraries and stuff which will probably be in those
pesky '-devel' packages we'll talk about later. There's much more.
> I guess my fundamental question is what does clamd do that clamav
> does not and vice versa?
It's not like that. ClamAV includes a thing called a daemon, which
you can start and allow to run indefinitely. It just sits there, in
about a gigabyte of RAM, waiting for you to ask it to scan something.
That daemon is clamd. I'm running two of them on the machine that's
going to send this mail to you - but then it's a mail server. You'd
normally be expected to ask the daemon to scan something by using a
command-line tool like 'clamdscan' or by integrating something like
'clamav-milter' into your mail system. But if you don't want to run
a daemon 24/7 you can just not start it, and instead use the command
line tool 'clamscan' will do something like what 'clamdscan' would do
- but it will first have to load all the signatures, which takes time.
> ... security guy in me wants to avoid installing unneeded applications ...
The security guy in me says at the moment, the biggest threat to your
system is _you_.
> If it helps, my intent is to do both scheduled and on-access scanning
It helps, sort of. I'd still want to know why.
You need clamd for the on-access part unless you won't mind waiting a
couple of minutes for _every_ on-access scan while the scanner process
loads and verifies getting on for ten million signatures.
> I’m considering setting the OnAccessIncludePath to /home and /var.
I'd be more selective than that. Your system logs will be in /var,
for example, and it's most unlikely that they'll represent any kind of
a threat. You'd be far better off learning about them, and trawling
through them whenever you get a spare moment. I'd suggest 'tripwire'
or similar if I thought it was worth the bother but I've found nothing
to beat good hygiene. Are you running a firewall? Do you know what
it's doing? Do you look at the logs?
> would I be better served going ... (perhaps all the way to /)
Don't do that. There are all sorts of bits of the OS that you really
don't want to scan.
> I’m just seeking the benefit of other’s experience in use.
I have experience. I never scan linux boxes with ClamAV. Very rarely
I might mount a Windows filesystem on a Linux box to scan it, but it's
usually better to use Windows tools to do that. They're more flexible
and they're better at it and there are many more of them. If I didn't
run mail servers, I wouldn't bother with ClamAV at all.
> Clamav-scanner-systemd and clamav-server-systemd ...
Talk to the package people about those. I don't use systemd anyway.
> Finally, I see clamav-devel contains a lot of other stuff ...
Anything '-devel' in package terms generally means a bunch of files
which you'll need if you're going to compile something from source.
There might be many such -devel packages needed for any one source
package, it often won't be obvious what they are until the compiler
barks error message at you. Sometimes not even then.
> And, what I hope is my last question...
But you said "finally"! :)
> ... some documents refer to scan.conf and some refer to clamd.conf
The daemon I talked about uses 'clamd.conf'. There are other
configuration files but I have no idea what 'scan.conf' might be
and there is no such file on any of my mail servers.
> Sorry this turned into a novel, but I’d appreciate any insights any
> of you may have.
Take some quality time out to do some reading. Unless you think that
learning stuff can't possibly be a waste of time (something with which
I'd tend to agree), ClamAV _might_ just be using time that could much
better be employed learning about your systems.
I'd have liked to spend more time on this but I have to go.
More information about the clamav-users