This still has value as it can help catch things in action. It doesn't replace periodic scans either to catch malware discovered since the initial scan.
There are a variety of ways of doing this if scanning everything in one shot isn't feasible. One option would be to split files up using a hashtable based on their name. This has the advantage of not needed to track any state, nor do you need to read every file (to hash the content) to determine whether the file has been scanned recently. On top of this, you could track hashes of scanned files so that you can tell how recently a duplicate copy of a file was scanned, avoiding the need to rescan duplicates, even across buckets. You would still want to use tripwire to scan new/modified files immediately. You might also consider scanning older files less frequently as it is less likely that an older file will contain a 8 month old 0-day that was just discovered. It all depends on your tolerance for risk of malware vs available resources. Lucky for me, the volume of data under my responsibility can be scanned both at creation and nightly without further stress. On Wed, Mar 21, 2018, at 18:41, Paul Kosinski wrote: > A few years ago, when Tripwire was no longer free, I set up a "scan > once" environment for ClamAV, identifying files using SHA1 hashing > (with a few 'stat' results like inode and timestamp for good measure). > > I gave up when I realized that even if a file had already been scanned, > it might have contained "0-day" malware when it was scanned. This could > make it quite nasty, especially if ClamAV is behind in 0-day detection. > > > On Wed, 21 Mar 2018 16:56:06 -0700 > Dennis Peterson <denni...@inetnw.com> wrote: > > > It is possible to integrate ClamAV and Tripwire to get to a scan-once > > environment. Include puppet or CFEngine for a more complete tool. > > > > dp > > > > On 3/20/18 5:01 AM, Micah Snyder (micasnyd) wrote: > > > Good morning Tsutomu, > > > > > > Al is quite correct. clamd and clamdscan maintain no memory of > > > what has been scanned before. > > > > > > In your ordinary use case, you simply run clamdscan over whatever > > > you want to scan. You can exclude specific directories in your > > > configuration if you want to point clamdscan at a high level > > > directory to scan many items. > > > > > > In truth, I've never tried accessing the files as they were > > > scanned, but I do not believe that there any reason why the files > > > would be locked by ClamAV except in the following case. > > > > > > On newer versions of Linux that have been built with > > > CONFIG_FANOTIFY=y enabled, you can configure clamd to monitor > > > directories. An additional option may be enabled that we call > > > "OnAccessPrevention" can intentionally block access to the file > > > until it has been scanned and will deny access if the file is > > > flagged. OnAccessPrevention requires your kernel has been built > > > with CONFIG_FANOTIFY_ACCESS_PERMISSION=y. If you're interested in > > > trying this out, please read > > > http://blog.clamav.net/2016/03/configuring-on-access-scanning-in-clamav.html > > > > > > Sadly, OnAccess scanning and prevention only exist for Linux at > > > this time. > > > > > > > > > Micah Snyder > > > ClamAV Development > > > Talos > > > Cisco Systems, Inc. > > > > > > > _______________________________________________ > clamav-users mailing list > clamav-users@lists.clamav.net > http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users > > > Help us build a comprehensive ClamAV guide: > https://github.com/vrtadmin/clamav-faq > > http://www.clamav.net/contact.html#ml _______________________________________________ clamav-users mailing list clamav-users@lists.clamav.net http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
