Hi there,
On Fri, 18 Oct 2019, Ian via clamav-users wrote:
>> On Oct 18, 2019, at 12:02 AM, G.W. Haywood via clamav-users <clamav-users@lists.clamav.net> wrote:
>> On Thu, 17 Oct 2019, Ian via clamav-users wrote:
>>
>>> /usr/bin/clamdscan -m -i --no-summary /
>>
>> Don't do that.
>
> Government regulations require that I scan the entire filesystem
> daily --
Which government is this, and which regulations? Do the regulations
specify the minimum acceptable probability (*) of finding something
malicious (given such a thing is in fact there) with your choice of
scanning tool? And acceptable characteristics of the infrastructure
supporting the chosen scanning engine, the frequency of updates, the
methods to be used by said engine, and the security systems in place
which prevent compromise of all that? If not, the bald imprecation
(for that's all it is) "scan daily" seems to be completely pointless.
(*) I'd estimate for ClamAV you're looking at about 30% on a good day,
and if it's a zero-day exploit, obviously, zero percent, for anything,
not just ClamAV. If you don't like these numbers, read my occasional
posts about it in the archives of this list, going back several years.
> I've already excluded the folders that contain pseudo files.
That's good - although if you'd mentioned it earlier it would be much
easier to believe. The main trouble is that things like your command
to scan '/' get written into internet folklore like the 'mx' mechanism
in your SPF record and then everybody does it, because that's what it
says on the Internet. It's really much better if you actually think
about it a bit first.
> Also, it seems like bad advice to omit scanning the folder most
> likely to find a payload from a malicious actor (because file
> permissions tend to be lax in /tmp), but I could be misinterpreting
> what "Don't do that" means.
You are indeed misinterpreting. I didn't advise "don't scan /tmp",
and it seems to me to be a little churlish to accuse me of giving bad
advice when (a) I didn't give that advice and (b) I'm actually trying
to help. And if you're worried about file permissions in /tmp you are
presumably capable of doing something about it (although there might
be good reason to be cautious when you start along that kind of path).
> This doesn't seem like a difficult problem...
I think I'd be disappointed if I told clamd to scan everything in a
directory tree, and it didn't try to do that. On the other hand it's
not the sort of thing I'd generally do, unless the tree was a client's
Windows filesystem that I'd mounted temporarily to take a peek at it.
Read the man page for clamd, especially the bit that talks about where
it should store its temporary files.
Do these log messages actually matter? As I mentioned to someone else
recently, there's always syslog-ng.
Is there a reason you think something nasty might be able to get into
this filesystem that you're, er, religiously scanning daily? And, if
there is, would it not make more sense to deal with that, instead of
waiting for it to get in, and then playing hide'n'seek with it? For
once it's in, all bets are off and you'd best buy some new drives (of
course you can't even really trust brand new drives any more). FWIW
the last time I saw a compromised Linux box was almost twenty years
ago, but I know it does still happen because people will insist on a
pretty-looking blog, or forum, or whatever, and then they don't seem
to bother patching things, even when the exploit's been in the news
for a week. Even when they're a computer security company.
Do these government regulations say anything about patching software?
Judging by the number of ransomware outbreaks in US government bodies
I guess maybe not. (You seem to be on PDT, so I guessed again. :)
--
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