Mailing List Archive

[clamav-users] Support for GPFS / real-time antivirus checks
Hi all,

we have a server operating RHEL 6.x and which is using GPFS as a file
system. We process high volume data on this server and are evaluating
whether clamAV / clamd is a feasible solution to run AV scans against
the processed data.

As I could not find an official page that lists features / supported
platforms, etc. I would like to ask the community:

- Does clamAV / clamd support GPFS as a filesystem?
- Is it feasible to enable real-time antivirus checks / monitoring
- Do you believe that clamAV / clamd is suitable to scan high volume data?
- Are there any upper limits on the size of the volume to be scanned
(besides the 4GB max. file size)

Thanks in advance,
André

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml
Re: [clamav-users] Support for GPFS / real-time antivirus checks [ In reply to ]
Hi there,

On Thu, 17 Mar 2022, An Schall via clamav-users wrote:

> we have a server operating RHEL 6.x and which is using GPFS as a file
> system. We process high volume data on this server and are evaluating
> whether clamAV / clamd is a feasible solution to run AV scans against
> the processed data.

Perhaps you can be a little more forthcoming about the data?

> As I could not find an official page that lists features / supported
> platforms, etc.

If what you need to know can not be found at

https://docs.clamav.net/

please feel free to list the deficiencies here, or perhaps better
raise an issue on Github:

https://github.com/Cisco-Talos/clamav/issues/

> I would like to ask the community:
>
> - Does clamAV / clamd support GPFS as a filesystem?

ClamAV does not care what filesystem you use to store data - it can be
used to scan directly a stream of data which is not in any filesystem.
Most filesystems thesedays support multi-user, multi-tasking operating
systems and you might need to quarantine incoming data so that it can
be scanned before you permit access to it by a potentially vulnerable
application, but that's up to you and how you arrange things. There's
a daemon called 'clamonacc' which can use operating system features to
prevent access to suspect files 'on the fly' but, if I understand your
requirements at all, the performance might be an issue.

> - Is it feasible to enable real-time antivirus checks / monitoring

You need to define the terms which you are using. I do not know what
"real-time" means in that sentence. If it means can you scan data as
it arrives somewhere on a wire then as per the previous paragraph the
answer is yes. If it means can you run a daemon which prevents access
to suspect files by scanning them when some other process attempts to
read them, the answer is also yes with the above performance caveat.
In both cases you should consider the *detection* performance too, see
my final comment below.

I think most people use ClamAV without thinking very much about it to
scan a filesystem every once in a while. But ClamAV is more a toolkit
than it is an application and you can use it in many ways. I use it
only to scan electronic mail, primarily to stop spam and other junk.

> - Do you believe that clamAV / clamd is suitable to scan high volume data?

Again please define your terms, and in this case suggest what hardware
you might be planning to use. Obviously you can scale the capacity of
your scanning system to suit the volumes of data to be scanned simply
by applying more hardware (money) to the problem. Whatever you do, if
you are going to scan petabytes of unknown data for many millions of
disparate threats it's going to take some effort (and probably time).

> - Are there any upper limits on the size of the volume to be scanned
> (besides the 4GB max. file size)

Although the documentation might state otherwise in places, unless I
have missed something (since the move to Github I haven't been able to
make head nor tail of the ClamAV changes) the maximum is 2GB, not 4GB.
The limit is on the size of a single file (or - I believe - the length
of a data stream) and not the size of a volume in the filesystem. The
sizes of filesystems and volumes are irrelevant to ClamAV as it simply
uses the operating system facilities to access the scanned data, just
like any other application. Typically a ClamAV process while scanning
will use about 1GByte of RAM. This can be a single-use process which
loads its signature database on demand (the database can take a little
time to load, as it usually contains of the order of ten million sigs)
or it can be a long-lived daemon - 'clamd'. In either case there are
numerous configuration options which can set limits, including but not
limited to the size of individual files. You can, and I occasionally
do, run multiple clamd daemons. In my case this is usually about test
and experiment but you could do the same for parallel processing if it
appears to you to be necessary. A clamd daemon can take advantage of
multi-cored hardware, and, given enough RAM, you can run more than one
instance of clamd on a system. The 'clamonacc' utility itself uses a
'clamd' daemon to do its actual scanning.

Finally please consider the probability that ClamAV will find what you
think you are looking for. In my experience the people who ask the
sorts of questions which you are asking never seem to consider that a
threat might evade detection, and there's a somewhat depressingly good
chance that it will do just that - no matter what scanner you use. If
you search the archives of this mailing list you'll find some numbers,
but on a *very* good day one in five will get through. On a bad day,
just one of those will compromise your entire network.

HTH.

--

73,
Ged.

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml