Re: [clamav-users] Can't detect deceptive URL's as infected !!

[Steve Basford]

On Tue, December 11, 2018 1:58 pm, Sunny Marwah wrote:

Hi Sunny/All,

Here's the summary

The phishing attempt looks like this html code:

h-t-t-p-s:/-/-pastebin DOT com/TL5WUJZh

This first link is just a hijacked graphic and won't be in safebrowsing...

h-t-t-p-s:-/-/gokdenizhealthtourism DOT com/js/logo.gif

This next link, is the bad" phishing link is:

h-t-t-p-s:/-/-nompao DOT com/boa.php

The above link is currently blank and isn't in currently safebrowsing,
however, you can report it here:

https://safebrowsing.google.com/safebrowsing/report_badware/

VirusTotal is showing a clean link too on the phishing link:

https://www.virustotal.com/#/url/27abfb7ec2849ebadf75dcf899bc0f2aa3a491897bcef3ad2179ed30bb2eb258/detection


You can submit the sample to ClamAV to add detection of the phish contents
here (regardless of the url's that are being used)

https://www.clamav.net/reports/malware

-- 
Cheers,

Steve
Twitter: @sanesecurity

___
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] Question about LLVM...

[J.R.]

I've googled to no end, but haven't been able to come up with anything
except a few snips mentioning LLVM and bytecode here and there...

I'm curious exactly what the benefit would be to use LLVM, is there
much of a performance gain over the built-in (non-llvm) bytecode
interpreter? Is it an expanded feature set? Why the limitation of
using only such old versions of LLVM?

The last time I looked at the manual it only mentioned compilation
options, and that's it... The current link to the ClamAV manual is
broken on the website too, fyi... :(

Not complaining, just curious...
___
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] A workaround for the major ClamAV DB update delays we have been experiencing

[Dennis Peterson]

You know the daily.cvd file is now larger than the main.cvd file, so you are 
burning up a lot of bandwidth if your world-facing ClamAV mirror is ignoring 
cdiff files. If it is using freshclam then it is using cdiffs and merging them 
as part of the process of mirroring. In that case your clients won't see the 
cdiff files which is perfectly acceptable. I used to use a proxy when many 
systems were co-located and it was very effective and was also being used for 
other purposes. Life is much simpler now that I'm retired.


dp

On 12/11/18 11:45 AM, Paul Kosinski wrote:

Ever since we set up a local mirror on our LAN, we have not been using
cdiffs. The reason for this is that I followed the procedure outlined
on the ClamAV website (about 2/3 down the page) at:

   http://www.clamav.net/documents/clamav-virus-database-faq

where it says:

[Q] I’m running ClamAV on a lot of clients on my local network.  Can I serve 
the cvd files from a local server
 so that each client doesn’t have to download them from your servers?
   
[A] Sure, you can find more details on our Mirror page.
   
If you want to take advantage of incremental updates, install a proxy server and then

 configure your freshclam clients to use it (watch for the HTTPProxyServer 
parameter in man freshclam.conf).
   
The second possible solution is to:
   
   Configure a local webserver on one of your machines (say machine1.mylan)
   
   Let freshclam download the *.cvd files from http://database.clamav.net to the webserver’s DocumentRoot.
   
   Finally, change freshclam.conf on your clients so that it includes:
   
   DatabaseMirror machine1.mylan
   
   ScriptedUpdates off
   
   First the database will be downloaded to the local webserver and then the other clients

 on the network will update their copy of the database from it.
   
   Important: For this to work, you have to add ScriptedUpdates off on all of your machines!


Since I didn't want to set up a proxy server for this purpose, I used
the 2nd solution (and a very trivial web server). Thus, cvd files only.

P.S. I am now thinking about trying the BOS vs IAD test for cdiff
files. But, even if cdiff files always work without any delays, doesn't
"scripted update" on occasion have to back off to downloading full cvds?

P.P.S. Thanks for the curl help!



On Mon, 10 Dec 2018 20:34:45 -0800
Dennis Peterson  wrote:


You were using curl (I did remember that after I posted as I'd helped
you sort out curl options to do what you wanted) to explore what was
available on the servers compared to what was on the DNS TXT record,
and that was outside process. It also ignored cdiff files that may
have been available in a version that matched the TXT record. The
purpose of the cdiff files is to cut down on bandwidth.

dp

On 12/10/18 6:34 PM, Paul Kosinski wrote:

We ARE using freshclam to perform the actual update. And always have
been!

We've only been using curl (not wget, if that matters) to pull the
first few bytes of the cvd to see if its version number matches
what the DNS TXT query said.

We do this because, after the conversion to Cloudflare, we were
getting lots of FAILURES where *freshclam* said things were out of
sync (and eventually disabled all the mirrors).

And we have recently seen that our Web server sometimes can get the
new updates (from IAD) *hours* before our main LAN does (from BOS).

P.S. It's been quite frustrating getting some replies seemingly
based on assumptions that we are doing things we shouldn't, when we
aren't in fact doing those things. (Like not using freshclam.)



On Mon, 10 Dec 2018 16:46:42 -0800
Dennis Peterson  wrote:


Exactly right. We can't be blaming the ClamAV process when we don't
use the ClamAV process. People that don't use freshclam should have
no expectation of high reliability. In fact any expectations are
baseless when the wrong tools are employed.

dp

On 12/9/18 5:44 AM, Joel Esler (jesler) wrote:

As it should be.  No one should be downloading the daily and main,
(although thousands are), cdiffs were created for a reason.

Sent from my  iPhone


On Dec 9, 2018, at 06:58, Eric Tykwinski 
wrote:

   From back in archives, I think he’s using wget to just pull the
files, but freshclam would just pull the cdiffs and keep you up
to date on the next check.

___
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

Re: [clamav-users] Can't detect deceptive URL's as infected !!

[Dennis Peterson]

Yes - the extension can be one or the other. The other thing to check is the 
file ownership and permissions, and finally to search your clamd.log file (or 
what ever it is called on your system) for "FOUND". If it is a useful signature 
source your logs should indicate clamd is finding targets from the safebrowsing 
signature file. In your freshclam log you should see the safebrowing file is 
being updated from time to time. My own system, with rare exception, only ever 
finds Sane Security signatures, and most http links are caught by my milter via 
dns-based URLBL blacklists before it sends the messages to Clamd.


dp

On 12/11/18 3:54 AM, Sunny Marwah wrote:

I can see below files in /var/lib/clamav/ directory :

main.cvd
bytecode.cvd
safebrowsing.cld
daily.cld
mirrors.dat

But it is 'safebrowsing.cld', not 'safebrowsing.cvd'.

Is it Ok ??



On Tue, Dec 11, 2018 at 1:47 PM Dennis Peterson > wrote:


In your ClamAV signature folder does there exist a safebrowsing.cvd file?

dp

On 12/10/18 9:46 PM, Sunny Marwah wrote:
>
> Same question again : Chrome don't open malicious links due to labeling
them
> dangerous as per "Safebrowsing". Then why ClamAV is not able to identify
such
> malicious links when "Safebrowsing" option is already enabled ??

___
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



--
Regards
Sunny
System Engineer
Mob : +91 9711155549


___
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

Re: [clamav-users] Question about LLVM...

[Micah Snyder (micasnyd)]

Sorry about the broken links on the website and in the clamav-faq manual pages. 
 Our web dev team is actively working on integrating the newly remodeled user 
manual into the website.

The bytecode interpreter was nonfunctional for a long time but was fixed a few 
years ago. This is why LLVM was prioritized over the bytecode compiler.

Functionally, from an outside perspective, the feature set of using bytecode 
interpreter vs LLVM is the same. The cost/benefit analysis of LLVM-JIT vs 
Interpreter hinges on whether or not executing native code is sufficiently 
faster than interpreting the bytecodes to outweigh the cost of JIT compilation. 
Our bytecode signatures themselves are relatively small and are relatively few, 
so the advantage of executing native code vs the time lost JIT compiling the 
bytecode is, I'm told, negligible. The developers who did the initial 
benchmarking on the subject have since left the team and while I've been told 
that the performance is "about the same", I don't have any figures to back up 
that up. If anyone out there decides to do additional research on the subject, 
do note that bytecode functions are only executed for certain file types, so 
benchmark findings will vary by file type.

The TL;DR is that we're not aware of any significant advantage of using LLVM 
over the bytecode interpreter at this time.

Regarding the reason for only supporting older versions of LLVM:  It takes time 
to update to use newer APIs.  The LLVM project has been moving pretty fast and 
we simply haven't prioritized dev and test time towards updating our LLVM 
support.  In fact, Debian provides a patch to ClamAV to support LLVM 3.7-3.9, 
but we haven't had the time to properly integrate and test it.  Because the 
bytecode interpreter is working so well, we're focusing our efforts on other 
tasks.

Regards,
Micah

Micah Snyder
ClamAV Development
Talos
Cisco Systems, Inc.


On Dec 11, 2018, at 10:05 AM, J.R. 
mailto:themadbea...@gmail.com>> wrote:

I've googled to no end, but haven't been able to come up with anything
except a few snips mentioning LLVM and bytecode here and there...

I'm curious exactly what the benefit would be to use LLVM, is there
much of a performance gain over the built-in (non-llvm) bytecode
interpreter? Is it an expanded feature set? Why the limitation of
using only such old versions of LLVM?

The last time I looked at the manual it only mentioned compilation
options, and that's it... The current link to the ClamAV manual is
broken on the website too, fyi... :(

Not complaining, just curious...
___
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

Re: [clamav-users] Question about LLVM...

[J.R.]

Micah & Scott,

Thank you for the replies, you answered exactly what I was thinking
too based on posts referring to the built-in improvements and hush on
llvm.
___
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] Question about LLVM...

[Scott Kitterman]

On Tuesday, December 11, 2018 05:59:05 PM Micah Snyder wrote:
> Sorry about the broken links on the website and in the clamav-faq manual
> pages.  Our web dev team is actively working on integrating the newly
> remodeled user manual into the website.
> 
> The bytecode interpreter was nonfunctional for a long time but was fixed a
> few years ago. This is why LLVM was prioritized over the bytecode compiler.
> 
> Functionally, from an outside perspective, the feature set of using bytecode
> interpreter vs LLVM is the same. The cost/benefit analysis of LLVM-JIT vs
> Interpreter hinges on whether or not executing native code is sufficiently
> faster than interpreting the bytecodes to outweigh the cost of JIT
> compilation. Our bytecode signatures themselves are relatively small and
> are relatively few, so the advantage of executing native code vs the time
> lost JIT compiling the bytecode is, I'm told, negligible. The developers
> who did the initial benchmarking on the subject have since left the team
> and while I've been told that the performance is "about the same", I don't
> have any figures to back up that up. If anyone out there decides to do
> additional research on the subject, do note that bytecode functions are
> only executed for certain file types, so benchmark findings will vary by
> file type.
> 
> The TL;DR is that we're not aware of any significant advantage of using LLVM
> over the bytecode interpreter at this time.
> 
> Regarding the reason for only supporting older versions of LLVM:  It takes
> time to update to use newer APIs.  The LLVM project has been moving pretty
> fast and we simply haven't prioritized dev and test time towards updating
> our LLVM support.  In fact, Debian provides a patch to ClamAV to support
> LLVM 3.7-3.9, but we haven't had the time to properly integrate and test
> it.  Because the bytecode interpreter is working so well, we're focusing
> our efforts on other tasks.

And unfortunately the developer who was doing that work in Debian has moved on 
to other things, so we won't be providing patches for later versions.

Might it make sense in the next feature release to just kill off LLVM and move 
on.  That would certainly help with clarity and focus.

Scott K
___
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] Can't detect deceptive URL's as infected !!

[Al Varnell]

Sunny,

Please note that the reply was not from me, rather it was from "Micah Snyder 
(micasnyd)" , ClamAV Engineer. You need to ask him for any 
additional  details.

Also, you are correct that safebrowsing.cld is just an updated, decompressed 
version of safebrowsing.cvd.

-Al-

On Tue, Dec 11, 2018 at 05:58 AM, Sunny Marwah wrote:
> Hi Al,
> 
> Thanks for sharing that reply.
> 
> Do you mean ClamAV did not detect that file (containing deceptive link) as 
> 'Infected" in your scanning ?
> 
> FYI, i have also tried Google's Safebrowsing API to check such deceptive 
> links.
> 
> It was really strange to know that even Google's Safebrowsing lookup API did 
> not detect that file as 'Unsafe'. The reason behind is the deceptive link is 
> phishing link but not malware.
> 
> So Google's Safebrowsing lookup API will identify only Malware links as 
> 'Unsafe' but not all deceptive links. However, when i check the same URL on 
> "https://transparencyreport.google.com/safe-browsing/search 
> ", then it shows 
> 'site is unsafe' what i am actually looking for.
> 
> Regards
> Sunny
> 
> On Tue, Dec 11, 2018 at 5:28 PM Al Varnell  > wrote:
> Here was the earlier reply to your question
>  >.
> 
> Sent from my iPad
> 
> -Al-
> 
> On Dec 10, 2018, at 21:46, Sunny Marwah  > wrote:
>> Same question again : Chrome don't open malicious links due to labeling them 
>> dangerous as per "Safebrowsing". Then why ClamAV is not able to identify 
>> such malicious links when "Safebrowsing" option is already enabled ??  
>> 
>>> On Sat, Dec 8, 2018 at 9:00 PM Micah Snyder (micasnyd) >> > wrote:
>> Our replies may be getting filtered by your email provider because you 
>> included a malicious link in the email chain. :D  I removed the link from 
>> this reply. 
>> 
>>  
>> Micah Snyder
>> ClamAV Development
>> Talos
>> Cisco Systems, Inc.
>> 
>> 
>>> On Dec 8, 2018, at 9:17 AM, Sunny Marwah >> > wrote:
>>> 
>>> 
>>> Still no reply on this matter. 
> 
> 
> Regards
> Sunny
___
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] Can't detect deceptive URL's as infected !!

[Micah Snyder (micasnyd)]

Hi Sunny,

I meant to say that if I scanned a saved email file containing the malicious 
URL in an HTML link (i.e.   a href=link  ), then it will detect the link with 
the safebrowsing signature.  However, if the malicious URL is not an HTML link, 
for example if the email content is plain text, then the safebrowsing signature 
does not appear to alert.

Regards,
Micah

Micah Snyder
ClamAV Development
Talos
Cisco Systems, Inc.


On Dec 11, 2018, at 8:58 AM, Sunny Marwah 
mailto:sunnymar...@trepup.com>> wrote:

Hi Al,

Thanks for sharing that reply.

Do you mean ClamAV did not detect that file (containing deceptive link) as 
'Infected" in your scanning ?

FYI, i have also tried Google's Safebrowsing API to check such deceptive links.

It was really strange to know that even Google's Safebrowsing lookup API did 
not detect that file as 'Unsafe'. The reason behind is the deceptive link is 
phishing link but not malware.

So Google's Safebrowsing lookup API will identify only Malware links as 
'Unsafe' but not all deceptive links. However, when i check the same URL on 
"https://transparencyreport.google.com/safe-browsing/search;, then it shows 
'site is unsafe' what i am actually looking for.

Regards
Sunny

On Tue, Dec 11, 2018 at 5:28 PM Al Varnell 
mailto:alvarn...@mac.com>> wrote:
Here was the earlier reply to your question
.

Sent from my iPad

-Al-

On Dec 10, 2018, at 21:46, Sunny Marwah 
mailto:sunnymar...@trepup.com>> wrote:
Same question again : Chrome don't open malicious links due to labeling them 
dangerous as per "Safebrowsing". Then why ClamAV is not able to identify such 
malicious links when "Safebrowsing" option is already enabled ??

On Sat, Dec 8, 2018 at 9:00 PM Micah Snyder (micasnyd) 
mailto:micas...@cisco.com>> wrote:
Our replies may be getting filtered by your email provider because you included 
a malicious link in the email chain. :D  I removed the link from this reply.


Micah Snyder
ClamAV Development
Talos
Cisco Systems, Inc.


On Dec 8, 2018, at 9:17 AM, Sunny Marwah 
mailto:sunnymar...@trepup.com>> wrote:


Still no reply on this matter.


--
Regards
Sunny
System Engineer
Mob : +91 9711155549

___
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

Re: [clamav-users] A workaround for the major ClamAV DB update delays we have been experiencing

[Joel Esler (jesler)]

Cloudflare's cache timeout is set to 5 seconds.  So, I would doubt that 
Cloudflare's cache is the issue, it may be an ISP thing in the middle doing the 
caching, which is what Paul is guessing at this point, if I am following the 
thread correctly.

Out of an abundance of caution I did a worldwide flush of daily.cvd yesterday.  
Which caused everyone to get a new copy if it didn't match what they had.  This 
resulted in about 3TB of traffic in 10 minutes, but after that it settled back 
down.  We're still a bit higher than normal, as I eased some of the "you're 
going to fast" restrictions.  (I have a rate limiter set up, if you are 
downloading 100 cdiffs in 10 seconds, to rate limit the offender...)  I've 
disabled this for now

We're up to about 71TB a day right now and it seems to be holding steady.  Give 
it a couple more days and see if it comes back down.

--
Joel Esler
Manager, Communities Division
Cisco Talos Intelligence Group
http://www.talosintelligence.com

> On Dec 10, 2018, at 9:56 PM, Eric Tykwinski  wrote:
> 
> Paul,
> 
> Sorry some of this confusion is probably my fault trying to help without 
> going back to the whole thread.
> 
>> On Dec 10, 2018, at 9:34 PM, Paul Kosinski  wrote:
>> 
>> We ARE using freshclam to perform the actual update. And always have
>> been!
>> 
>> We've only been using curl (not wget, if that matters) to pull the first
>> few bytes of the cvd to see if its version number matches what the DNS
>> TXT query said.
>> 
>> We do this because, after the conversion to Cloudflare, we were getting
>> lots of FAILURES where *freshclam* said things were out of sync (and
>> eventually disabled all the mirrors).
> 
> Have you tried what I did below?  I.E. curl/wget/telnet whatever your flavor 
> of the day, and pull the newest cdiff?
> If you’re getting a 404, that’s definitely an issue.  
> 
> My guess is that it’s actually timing out though, and could be more of an 
> issue troubleshooting.
> Is it local, ie an IDP getting stuck scanning the files, or remotely 
> freshclam itself is timing out on BOS pulling the update from ClamAV and 
> caching it before you can download it.
> 
>> And we have recently seen that our Web server sometimes can get the new
>> updates (from IAD) *hours* before our main LAN does (from BOS).
> 
> Those hours before are only checking the CVDs, which can and probably are 
> cached on CloudFlare so not up to date.
> My guess is that there are just more people in Boston using Clam, so the 
> cache last the longest.
> 
>> P.S. It's been quite frustrating getting some replies seemingly based on
>> assumptions that we are doing things we shouldn't, when we aren't in
>> fact doing those things. (Like not using freshclam.)
> 
> I would agree, this has gone on a long time from my recollection, which is 
> why I jumped in and started looking at it.
> Definitely, I did hop on without all the facts and was just trying to figure 
> out on the fly what’s going on, so my bad on that.
> 
> When in doubt, I usually pull a pcap on a server.  There’s a lot of factors 
> that can come into play, but actually with clam only using http, this 
> actually makes it a lot easier.
> 
> Sincerely,
> 
> Eric Tykwinski
> 
> 
> ___
> 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



smime.p7s
Description: S/MIME cryptographic signature
___
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] A workaround for the major ClamAV DB update delays we have been experiencing

[Al Varnell]

I have to support you in that this guidance has been there for many years now, 
but I've never really understood why that was necessary. Obviously this method 
is part of the problem that Joel has been describing about the number of users 
always downloading the .cvd and it also greatly increases local network 
traffic. 

I'm not in a position to come up with a better solution, but it would seem 
there should be a more cost-effective solution in cases where a local mirror is 
required.

-Al-
ClamXAV User

On Tue, Dec 11, 2018 at 11:45 AM, Paul Kosinski wrote:
> Ever since we set up a local mirror on our LAN, we have not been using
> cdiffs. The reason for this is that I followed the procedure outlined
> on the ClamAV website (about 2/3 down the page) at:
> 
>  http://www.clamav.net/documents/clamav-virus-database-faq 
> 
> 
> where it says:
> 
> [Q] I’m running ClamAV on a lot of clients on my local network.  Can I serve 
> the cvd files from a local server
>so that each client doesn’t have to download them from your servers?
> 
> [A] Sure, you can find more details on our Mirror page.
> 
>   If you want to take advantage of incremental updates, install a proxy 
> server and then
>configure your freshclam clients to use it (watch for the HTTPProxyServer 
> parameter in man freshclam.conf).
> 
>   The second possible solution is to:
> 
>  Configure a local webserver on one of your machines (say machine1.mylan)
> 
>  Let freshclam download the *.cvd files from http://database.clamav.net 
>  to the webserver’s DocumentRoot.
> 
>  Finally, change freshclam.conf on your clients so that it includes:
> 
>  DatabaseMirror machine1.mylan
> 
>  ScriptedUpdates off
> 
>  First the database will be downloaded to the local webserver and then 
> the other clients
>on the network will update their copy of the database from it.
> 
>  Important: For this to work, you have to add ScriptedUpdates off on all 
> of your machines!
> 
> Since I didn't want to set up a proxy server for this purpose, I used
> the 2nd solution (and a very trivial web server). Thus, cvd files only.
> 
> P.S. I am now thinking about trying the BOS vs IAD test for cdiff
> files. But, even if cdiff files always work without any delays, doesn't
> "scripted update" on occasion have to back off to downloading full cvds?
> 
> P.P.S. Thanks for the curl help!
___
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] Can't detect deceptive URL's as infected !!

[Dennis Peterson]

In your ClamAV signature folder does there exist a safebrowsing.cvd file?

dp

On 12/10/18 9:46 PM, Sunny Marwah wrote:


Same question again : Chrome don't open malicious links due to labeling them 
dangerous as per "Safebrowsing". Then why ClamAV is not able to identify such 
malicious links when "Safebrowsing" option is already enabled ??


___
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] A workaround for the major ClamAV DB update delays we have been experiencing

[Paul Kosinski]

Ever since we set up a local mirror on our LAN, we have not been using
cdiffs. The reason for this is that I followed the procedure outlined
on the ClamAV website (about 2/3 down the page) at:

  http://www.clamav.net/documents/clamav-virus-database-faq

where it says:

[Q] I’m running ClamAV on a lot of clients on my local network.  Can I serve 
the cvd files from a local server
so that each client doesn’t have to download them from your servers?
  
[A] Sure, you can find more details on our Mirror page.
  
   If you want to take advantage of incremental updates, install a proxy server 
and then
configure your freshclam clients to use it (watch for the HTTPProxyServer 
parameter in man freshclam.conf).
  
   The second possible solution is to:
  
  Configure a local webserver on one of your machines (say machine1.mylan)
  
  Let freshclam download the *.cvd files from http://database.clamav.net to 
the webserver’s DocumentRoot.
  
  Finally, change freshclam.conf on your clients so that it includes:
  
  DatabaseMirror machine1.mylan
  
  ScriptedUpdates off
  
  First the database will be downloaded to the local webserver and then the 
other clients
on the network will update their copy of the database from it.
  
  Important: For this to work, you have to add ScriptedUpdates off on all 
of your machines!

Since I didn't want to set up a proxy server for this purpose, I used
the 2nd solution (and a very trivial web server). Thus, cvd files only.

P.S. I am now thinking about trying the BOS vs IAD test for cdiff
files. But, even if cdiff files always work without any delays, doesn't
"scripted update" on occasion have to back off to downloading full cvds?

P.P.S. Thanks for the curl help!



On Mon, 10 Dec 2018 20:34:45 -0800
Dennis Peterson  wrote:

> You were using curl (I did remember that after I posted as I'd helped
> you sort out curl options to do what you wanted) to explore what was
> available on the servers compared to what was on the DNS TXT record,
> and that was outside process. It also ignored cdiff files that may
> have been available in a version that matched the TXT record. The
> purpose of the cdiff files is to cut down on bandwidth.
> 
> dp
> 
> On 12/10/18 6:34 PM, Paul Kosinski wrote:
> > We ARE using freshclam to perform the actual update. And always have
> > been!
> >
> > We've only been using curl (not wget, if that matters) to pull the
> > first few bytes of the cvd to see if its version number matches
> > what the DNS TXT query said.
> >
> > We do this because, after the conversion to Cloudflare, we were
> > getting lots of FAILURES where *freshclam* said things were out of
> > sync (and eventually disabled all the mirrors).
> >
> > And we have recently seen that our Web server sometimes can get the
> > new updates (from IAD) *hours* before our main LAN does (from BOS).
> >
> > P.S. It's been quite frustrating getting some replies seemingly
> > based on assumptions that we are doing things we shouldn't, when we
> > aren't in fact doing those things. (Like not using freshclam.)
> >
> >
> >
> > On Mon, 10 Dec 2018 16:46:42 -0800
> > Dennis Peterson  wrote:
> >
> >> Exactly right. We can't be blaming the ClamAV process when we don't
> >> use the ClamAV process. People that don't use freshclam should have
> >> no expectation of high reliability. In fact any expectations are
> >> baseless when the wrong tools are employed.
> >>
> >> dp
> >>
> >> On 12/9/18 5:44 AM, Joel Esler (jesler) wrote:
> >>> As it should be.  No one should be downloading the daily and main,
> >>> (although thousands are), cdiffs were created for a reason.
> >>>
> >>> Sent from my  iPhone
> >>>
>  On Dec 9, 2018, at 06:58, Eric Tykwinski 
>  wrote:
> 
>    From back in archives, I think he’s using wget to just pull the
>  files, but freshclam would just pull the cdiffs and keep you up
>  to date on the next check.

___
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] Can't detect deceptive URL's as infected !!

[Sunny Marwah]

I can see below files in /var/lib/clamav/ directory :

main.cvd
bytecode.cvd
safebrowsing.cld
daily.cld
mirrors.dat

But it is 'safebrowsing.cld', not 'safebrowsing.cvd'.

Is it Ok ??



On Tue, Dec 11, 2018 at 1:47 PM Dennis Peterson  wrote:

> In your ClamAV signature folder does there exist a safebrowsing.cvd file?
>
> dp
>
> On 12/10/18 9:46 PM, Sunny Marwah wrote:
> >
> > Same question again : Chrome don't open malicious links due to labeling
> them
> > dangerous as per "Safebrowsing". Then why ClamAV is not able to identify
> such
> > malicious links when "Safebrowsing" option is already enabled ??
>
> ___
> 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
>


-- 
Regards
Sunny
System Engineer
Mob : +91 9711155549
___
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] Can't detect deceptive URL's as infected !!

[Al Varnell]

Here was the earlier reply to your question
>.

Sent from my iPad

-Al-

On Dec 10, 2018, at 21:46, Sunny Marwah mailto:sunnymar...@trepup.com>> wrote:
> Same question again : Chrome don't open malicious links due to labeling them 
> dangerous as per "Safebrowsing". Then why ClamAV is not able to identify such 
> malicious links when "Safebrowsing" option is already enabled ??  
> 
>> On Sat, Dec 8, 2018 at 9:00 PM Micah Snyder (micasnyd) > > wrote:
> Our replies may be getting filtered by your email provider because you 
> included a malicious link in the email chain. :D  I removed the link from 
> this reply. 
> 
>  
> Micah Snyder
> ClamAV Development
> Talos
> Cisco Systems, Inc.
> 
> 
>> On Dec 8, 2018, at 9:17 AM, Sunny Marwah > > wrote:
>> 
>> 
>> Still no reply on this matter. 
___
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] Can't detect deceptive URL's as infected !!

[Sunny Marwah]

Hi Al,

Thanks for sharing that reply.

Do you mean ClamAV did not detect that file (containing deceptive link) as
'Infected" in your scanning ?

FYI, i have also tried Google's Safebrowsing API to check such deceptive
links.

It was really strange to know that even Google's Safebrowsing lookup API
did not detect that file as 'Unsafe'. The reason behind is the deceptive
link is phishing link but not malware.

So Google's Safebrowsing lookup API will identify only Malware links as
'Unsafe' but not all deceptive links. However, when i check the same URL on
"https://transparencyreport.google.com/safe-browsing/search;, then it shows
'site is unsafe' what i am actually looking for.

Regards
Sunny

On Tue, Dec 11, 2018 at 5:28 PM Al Varnell  wrote:

> Here was the earlier reply to your question
>  >.
>
> Sent from my iPad
>
> -Al-
>
> On Dec 10, 2018, at 21:46, Sunny Marwah  wrote:
>
> Same question again : Chrome don't open malicious links due to labeling
> them dangerous as per "Safebrowsing". Then why ClamAV is not able to
> identify such malicious links when "Safebrowsing" option is already enabled
> ??
>
> On Sat, Dec 8, 2018 at 9:00 PM Micah Snyder (micasnyd) 
> wrote:
>
> Our replies may be getting filtered by your email provider because you
>> included a malicious link in the email chain. :D  I removed the link from
>> this reply.
>>
>>
>> Micah Snyder
>> ClamAV Development
>> Talos
>> Cisco Systems, Inc.
>>
>>
>> On Dec 8, 2018, at 9:17 AM, Sunny Marwah  wrote:
>>
>>
>> Still no reply on this matter.
>>
>>

-- 
Regards
Sunny
System Engineer
Mob : +91 9711155549
___
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