Re: [clamav-users] Latest report on update "delays"

2018-10-22 Thread Gary R. Schmidt

On 23/10/2018 16:17, Paul Kosinski wrote:

Two observations: First, a smoothly working freshclam mechanism
shouldn't require workarounds.
Well, yes, but it works smoothly for a very large number of people, 
myself included.



And I suspect many ClamAV users
wouldn't be able to deal with workarounds like this.
This I disagree with - if they are bright enough to go looking for 
something like ClamAV then they'd be able to handle the trivial task of 
adding a line to a crontab file.



Second, any time freshclam fails due to an out-of-sync problem, there
has been a useless load on the mirrors (although I suppose using cdiffs
would significantly reduce the useless data transfer). Plus there is
useless load on the client machine and its LAN.
There is a load only on the mirrors you are accessing, the rest of them 
keep doing their job.


Have you absolutely ruled out the possibility of someone having set up a 
transparent proxy on your border router(s)?


Cheers,
GaryB-)
___
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


Re: [clamav-users] Latest report on update "delays"

2018-10-22 Thread Paul Kosinski
Two observations: First, a smoothly working freshclam mechanism
shouldn't require workarounds. And I suspect many ClamAV users
wouldn't be able to deal with workarounds like this.

Second, any time freshclam fails due to an out-of-sync problem, there
has been a useless load on the mirrors (although I suppose using cdiffs
would significantly reduce the useless data transfer). Plus there is
useless load on the client machine and its LAN.


On Tue, 23 Oct 2018 14:16:58 +1100
"Gary R. Schmidt"  wrote:

> On 23/10/2018 13:28, Paul Kosinski wrote:
> > "I'm convinced that [malware analysis] interval exceeds the delay
> > due to sync problems by such a margin that the first interval needs
> > as much focus as can be committed while the distribution issues are
> > handled at a lower priority."
> > 
> > I mainly agree (and I much appreciate the efforts of the ClamAV
> > team).
> > 
> > What we found, unfortunately, was that after the switch to
> > Cloudflare, the mirror sync problems observed by "stock" freshclam
> > resulted in all the mirrors being blacklisted, causing future
> > ClamAV virus updates to cease. This meant distribution issues
> > became extremely important.
> > 
> Would just adding a cron job that deletes "mirrors.dat" every so
> often be an acceptable work-around?
> 
> It amuses me that my mirrors.dat file contains five entries that all 
> point to the same IP address, that's just a bit pointless!
> 
>   Cheers,
>   GaryB-)
> ___
___
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


Re: [clamav-users] Latest report on update "delays"

2018-10-22 Thread Gary R. Schmidt

On 23/10/2018 13:28, Paul Kosinski wrote:

"I'm convinced that [malware analysis] interval exceeds the delay due to
sync problems by such a margin that the first interval needs as much
focus as can be committed while the distribution issues are handled at
a lower priority."

I mainly agree (and I much appreciate the efforts of the ClamAV team).

What we found, unfortunately, was that after the switch to Cloudflare,
the mirror sync problems observed by "stock" freshclam resulted in all
the mirrors being blacklisted, causing future ClamAV virus updates to
cease. This meant distribution issues became extremely important.

Would just adding a cron job that deletes "mirrors.dat" every so often 
be an acceptable work-around?


It amuses me that my mirrors.dat file contains five entries that all 
point to the same IP address, that's just a bit pointless!


Cheers,
GaryB-)
___
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


Re: [clamav-users] Latest report on update "delays"

2018-10-22 Thread Paul Kosinski
"I'm convinced that [malware analysis] interval exceeds the delay due to
sync problems by such a margin that the first interval needs as much
focus as can be committed while the distribution issues are handled at
a lower priority."

I mainly agree (and I much appreciate the efforts of the ClamAV team).

What we found, unfortunately, was that after the switch to Cloudflare,
the mirror sync problems observed by "stock" freshclam resulted in all
the mirrors being blacklisted, causing future ClamAV virus updates to
cease. This meant distribution issues became extremely important.

The problem of malware. sadly, is far more complicated than file
synchronization, partly because malware is open-ended and even
ill-defined. And then there's the nasty fact that the "halting problem"
makes program analysis theoretically impossible.

P.S. Who would scan outbound mail? The originating machine? It might be
totally compromised. The SMTP gateway of the originator's ISP? Don't
many already do that?




On Sun, 21 Oct 2018 17:15:51 -0700
Dennis Peterson  wrote:

> You should abandon the notion of first time perfect with these kinds
> of things. There is a false sense of urgency that is imposing a
> workload on a team that is providing a free produce and service. The
> tools for correcting a moment zero malware exists in the tool for the
> operator to use. The real problem is the discovery and validation and
> that is why moment zero solutions will never be possible.
> 
> There is a finite time required to receive a malware instance,
> discover it is a malware, discover what it applies to, and to create
> a signature that reasonably avoids false positives. I'm convinced
> that interval exceeds the delay due to sync problems by such a margin
> that the first interval needs as much focus as can be committed while
> the distribution issues are handled at a lower priority.
> 
> There are other probabilities - as an example, the probability that a
> new malware is sufficiently in the wild to pose a threat to an
> important number of recipients and which can be very low. Those can
> be queued for release cutting down on the number of low-value
> updates. And somebody has to decide what is an important number.
> 
> Evidence of self-replication is recognizable by the rate of increase
> of infestations and is data that can be used in setting priorities.
> How to collect that? How to collect any metrics? So far it is largely
> buzz generated by responders and which is largely anecdotal.
> 
> To be honest, many problems would be solved if all outbound mail were
> scanned in real time.
> 
> dp
> 
> On 10/20/18 8:10 AM, Paul Kosinski wrote:
> > Yes, file synchronization is difficult. But we *started out* using
> > the provided (i.e., standard) freshclam tool to update our
> > daily.cvd (etc.). I only built our current non-standard tool
> > (reading the file header) when the Cloudflare mirrors started
> > serving out-of-date file versions which caused freshclam to fail
> > and blacklist the mirror (which eventually resulted in all mirrors
> > being blacklisted).
> >
> > This says to me that the old, "standard", DNS TXT approach built in
> > to freshclam doesn't play well with Cloudflare (or similar
> > mirrors?).

> 
> 
___
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


Re: [clamav-users] request of support for flagging fraud domain

2018-10-22 Thread G.W. Haywood

Hi there,

On Mon, 22 Oct 2018, Dennis Peterson wrote:

On 10/21/18 6:09 AM, Darius Baumann wrote:

I want to submit the following fraud domain for flagging in ClamAV -
"servicemarket.su":


If you have no reason for accepting mail from the .su top level domain then just
block that and be done with it. Sometimes it's reasonable to take a broad brush
response to these problematic domains.


Quite so.  Countries too.  Here's our current country blacklist:

mail6:# >>> cat /etc/mail/eXtensibleMilter/country_blacklist
# This file populates a Perl hash of (country_code => value) pairs.
# The country code is the ISO-3166 two-letter country code, see
# for example https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2.
# The value should be a single digit:
# 2 - Reject all mail from this country code at the connect callback
# if the ASN is not whitelisted.
# 1 - Reject if not whitelisted elsewhere (which means message
# processing must continue beyond the connect callback).
AE => 2, AF => 2, AL => 2, AM => 2, AO => 2, AR => 2, AT => 1,
AU => 1, AZ => 2, BA => 1, BD => 2, BE => 1, BG => 2, BH => 1,
BI => 2, BJ => 1, BO => 2, BR => 2, BS => 2, BW => 1, BY => 2,
BZ => 2, CG => 2, CI => 2, CL => 2, CM => 1, CN => 2, CO => 2,
CR => 2, CV => 1, CZ => 2, DK => 1, DO => 2, DZ => 2, EC => 2,
EE => 1, EG => 2, ES => 1, ET => 1, FJ => 2, FK => 2, FM => 2,
FO => 2, GA => 2, GE => 1, GH => 2, GR => 2, GT => 2, HK => 1,
HN => 2, HR => 1, HT => 1, HR => 2, HU => 1, ID => 2, IL => 1,
IN => 2, IQ => 2, IR => 2, IS => 1, IT => 1, JM => 2, JO => 2,
JP => 2, KE => 2, KG => 2, KH => 2, KN => 2, KR => 2, KW => 2,
KZ => 2, LA => 1, LB => 2, LK => 1, LS => 2, LT => 2, LU => 2,
LV => 2, LY => 2, MA => 1, MD => 1, ME => 2, MK => 2, ML => 1,
MM => 2, MN => 2, MQ => 1, MR => 1, MU => 1, MV => 1, MX => 2,
MY => 2, MZ => 2, NG => 2, NI => 2, NO => 1, NP => 2, PA => 2,
PE => 2, PH => 2, PK => 2, PL => 2, PR => 1, PS => 1, PY => 2,
QA => 1, RO => 2, RS => 2, RU => 2, RW => 2, SA => 2, SC => 2,
SD => 1, SE => 1, SG => 2, SI => 1, SK => 2, SL => 1, SN => 2,
SV => 2, SY => 2, TG => 1, TH => 2, TJ => 1, TL => 1, TM => 1,
TN => 1, TR => 2, TT => 2, TW => 2, TZ => 2, UA => 2, UG => 2,
UY => 2, UZ => 2, VE => 2, VN => 2, ZA => 2, ZM => 1, ZW => 2,

Perhaps the OP should be talking to Steve @ Sanesecurity.

--

73,
Ged.
___
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