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

[Sunny Marwah]

Still no reply on this matter.

On Fri, Dec 7, 2018 at 6:17 PM Sunny Marwah  wrote:

> Hi Al Varnell,
>
> Below is the URL which was mentioned in HTML template :
>
> https://gokdenizhealthtourism.com/js/logo2.gif
>
> Chrome don't open it due to labeling it dangerous in as per
> "Safebrowsing". Then why ClamAV is not able to identify when "Safebrowsing"
> option is already enabled ??
>
> Looking to hear from you on this.
>
> Regards
> Sunny
>
> On Fri, Dec 7, 2018 at 5:50 PM Al Varnell  wrote:
>
>> If you won't provide the URL to the rest of us users, then we can't help
>> you. You'll have to wait to see if the development team gets back to you.
>>
>> -Al-
>>
>> On Fri, Dec 07, 2018 at 04:10 AM, Sunny Marwah wrote:
>>
>> Hi Al Varnell,
>>
>> I have already gone through https://www.clamav.net/documents/safebrowsing
>> .
>>
>> That URL i have already shared with one of ClamAV development team members
>>
>> I did not understand your point what you said --- "You will probably need
>> to obfuscate it in order to get it through the mail system, something like
>> httx://".
>>
>> My purpose behind using ClamAV is to scan Linux server and plus HTML
>> templates which we regularly receive on server.
>>
>> And the reason behind using "Safebrowing" option is to detect deceptive,
>> Phishing URL's in HTML templates in the same way as Chrome warns us before
>> opening such URL's. I want ClamAV to detect such files as "Infected" which
>> contain deceptive, Phishing URL's.
>>
>> Waiting for your quick and needful response.
>>
>> Regards
>> Sunny
>>
>> On Fri, Dec 7, 2018 at 5:22 PM Al Varnell  wrote:
>>
>>> Have your read the explanation at <
>>> https://www.clamav.net/documents/safebrowsing>?
>>>
>>> Please provide the phishing URL that is failing. You will probably need
>>> to obfuscate it in order to get it through the mail system, something like
>>> httx://
>>>
>>> -Al-
>>>
>>> On Fri, Dec 07, 2018 at 03:17 AM, Sunny Marwah wrote:
>>>
>>> Hello Micah & Team,
>>>
>>> Have not received any response on my last email.
>>>
>>> Also, i have enabled Safebrowsing option in freshclam.conf as suggested
>>> by you.
>>>
>>> Still i can see that ClamAV is not working properly. There is one file
>>> placed on server and there is one phishing URL available in that file. That
>>> URL is so deceptive that Chrome is not letting us open that URL due to
>>> labeling it as "Deceptive" URL.
>>>
>>> Why ClamAV is still not able to find that file as "Infected" in scanning
>>> even after enabling "Safebrowsing" option ??
>>>
>>> Waiting for your quick and needful response.
>>>
>>> Regards
>>> Sunny
>>>
>>> On Thu, Dec 6, 2018 at 4:41 PM Sunny Marwah 
>>> wrote:
>>>
 Hi Micah,

 Thanks for letting me know about enabling SafeBrowsing CVD option in
 ClamAV.

 Google safe browsing put a website in 3 categories mentioned below :
 1 Secure
 2 Info or Not secure
 3 Not secure or Dangerous

 Curious to know how ClamAV will categorize the HTML file. Let's say, if
 any "Note secure or Dangerous" URL is found, will ClamAV will show it as
 infected file in scanning summary ? If this is the case, i guess in case
 "Secure" URL is found, it will show as OK. And what if URL is found as
 "Info or Not secure" ?

 Regards
 Sunny


 On Thu, Dec 6, 2018 at 3:19 PM Micah Snyder (micasnyd) <
 micas...@cisco.com> wrote:

> It may be worth mentioning that in addition to the [optional]
> SafeBrowsing CVD that you can choose to include, ClamAV has just started
> including PhishTank signatures late last month.
>
> For those who curious, see https://lists.gt.net/clamav/virusdb/.
> PhishTank signatures are prefixed with Phishtank.Phishing.
>
>
> Micah Snyder
> ClamAV Development
> Talos
> Cisco Systems, Inc.
>
>
> On Dec 6, 2018, at 3:27 AM, Al Varnell  wrote:
>
> Frankly, I'm surprised that ClamAV finds any such URL's. They are way
> to dynamic (blacklisted one day and removed the next). ClamAV does malware
> detection over the long haul and trying to keep up with fraudulent web
> sites would be a full time job and better done by other means (e.g. Google
> Safe Browsing).
>
> -Al-
>
> On Wed, Dec 05, 2018 at 11:33 PM, Sunny Marwah wrote:
>
> Hello Team,
>
> We are using clamav-0.100.2 to scan few HTML email templates.
>
> Sometimes, there are deceptive URL's mentioned in those templates and
> that template should be detected as infected via ClamAV scan process.
>
> I can see weird output of ClamAV scan process. Sometimes it detect
> such templates as infected and sometimes, it does not detect them as
> infected. And the URL's i am talking about, are so deceptive that even
> Google chrome browser don't let us open these URL's and show us clear
> warning as "Dangerous" about deceptive website.
>
> Can you put your view

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

[Micah Snyder (micasnyd)]

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.

On Fri, Dec 7, 2018 at 6:17 PM Sunny Marwah 
mailto:sunnymar...@trepup.com>> wrote:
Hi Al Varnell,

Below is the URL which was mentioned in HTML template :


Chrome don't open it due to labeling it dangerous in as per "Safebrowsing". 
Then why ClamAV is not able to identify when "Safebrowsing" option is already 
enabled ??

Looking to hear from you on this.

Regards
Sunny

On Fri, Dec 7, 2018 at 5:50 PM Al Varnell 
mailto:alvarn...@mac.com>> wrote:
If you won't provide the URL to the rest of us users, then we can't help you. 
You'll have to wait to see if the development team gets back to you.

-Al-

On Fri, Dec 07, 2018 at 04:10 AM, Sunny Marwah wrote:
Hi Al Varnell,

I have already gone through https://www.clamav.net/documents/safebrowsing.

That URL i have already shared with one of ClamAV development team members

I did not understand your point what you said --- "You will probably need to 
obfuscate it in order to get it through the mail system, something like 
httx://".

My purpose behind using ClamAV is to scan Linux server and plus HTML templates 
which we regularly receive on server.

And the reason behind using "Safebrowing" option is to detect deceptive, 
Phishing URL's in HTML templates in the same way as Chrome warns us before 
opening such URL's. I want ClamAV to detect such files as "Infected" which 
contain deceptive, Phishing URL's.

Waiting for your quick and needful response.

Regards
Sunny

On Fri, Dec 7, 2018 at 5:22 PM Al Varnell 
mailto:alvarn...@mac.com>> wrote:
Have your read the explanation at 
?

Please provide the phishing URL that is failing. You will probably need to 
obfuscate it in order to get it through the mail system, something like 
httx://

-Al-

On Fri, Dec 07, 2018 at 03:17 AM, Sunny Marwah wrote:
Hello Micah & Team,

Have not received any response on my last email.

Also, i have enabled Safebrowsing option in freshclam.conf as suggested by you.

Still i can see that ClamAV is not working properly. There is one file placed 
on server and there is one phishing URL available in that file. That URL is so 
deceptive that Chrome is not letting us open that URL due to labeling it as 
"Deceptive" URL.

Why ClamAV is still not able to find that file as "Infected" in scanning even 
after enabling "Safebrowsing" option ??

Waiting for your quick and needful response.

Regards
Sunny

On Thu, Dec 6, 2018 at 4:41 PM Sunny Marwah 
mailto:sunnymar...@trepup.com>> wrote:
Hi Micah,

Thanks for letting me know about enabling SafeBrowsing CVD option in ClamAV.

Google safe browsing put a website in 3 categories mentioned below :
1 Secure
2 Info or Not secure
3 Not secure or Dangerous

Curious to know how ClamAV will categorize the HTML file. Let's say, if any 
"Note secure or Dangerous" URL is found, will ClamAV will show it as infected 
file in scanning summary ? If this is the case, i guess in case "Secure" URL is 
found, it will show as OK. And what if URL is found as "Info or Not secure" ?

Regards
Sunny


On Thu, Dec 6, 2018 at 3:19 PM Micah Snyder (micasnyd) 
mailto:micas...@cisco.com>> wrote:
It may be worth mentioning that in addition to the [optional] SafeBrowsing CVD 
that you can choose to include, ClamAV has just started including PhishTank 
signatures late last month.

For those who curious, see https://lists.gt.net/clamav/virusdb/.   PhishTank 
signatures are prefixed with Phishtank.Phishing.


Micah Snyder
ClamAV Development
Talos
Cisco Systems, Inc.


On Dec 6, 2018, at 3:27 AM, Al Varnell 
mailto:alvarn...@mac.com>> wrote:

Frankly, I'm surprised that ClamAV finds any such URL's. They are way to 
dynamic (blacklisted one day and removed the next). ClamAV does malware 
detection over the long haul and trying to keep up with fraudulent web sites 
would be a full time job and better done by other means (e.g. Google Safe 
Browsing).

-Al-

On Wed, Dec 05, 2018 at 11:33 PM, Sunny Marwah wrote:
Hello Team,

We are using clamav-0.100.2 to scan few HTML email templates.

Sometimes, there are deceptive URL's mentioned in those templates and that 
template should be detected as infected via ClamAV scan process.

I can see weird output of ClamAV scan process. Sometimes it detect such 
templates as infected and sometimes, it does not detect them as infected. And 
the URL's i am talking about, are so deceptive that even Google chrome browser 
don't let us open these URL's and show us clear warning as "Dangerous" about 
deceptive website.

Can you put your views behind such unpredictable behavior ?

If you want then i can report such URL's on your malware link for reporting.

Regards
Sunny
__

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

[Paul Kosinski]

Not sure what DNS caching would have to do with this. As I understand
"anycast", it happens at the IP address level. An anycast IP address
gets routed differently depending are where you are -- different
(regional) routers have different "next hops" for the IP address, and
it eventually ends up at a "nearby" server. This is in addition to the
fact that database.clamav.net resolves to 5 different IP addresses (all
of which are anycast IPs, I would guess).

The Cloudflare servers, although they have the same IP address(es) seem
to identify themselves by means of an HTTP header that they return:

  CF-RAY: 4852e02c35ae5a5c-BOS
  CF-RAY: 48526af5624356c3-IAD

Finally, AFAIK, I always get the same result for 

  "dig TXT current.cvd.clamav.net"

no matter where I 'dig' (or 'host') from.



On Fri, 7 Dec 2018 19:27:20 -0500
Eric Tykwinski  wrote:

> This is getting rather technical, and probably some of CloudFlare’s
> secret sauce. It sounds like the anycast DNS that cloudflare hosts
> isn’t really working, or at least I would assume that they are using
> anycast.
> 
> So you query current.cvd.clamav.net 
> but are getting different results at IAD and BOS.  Now next is the
> inclusion of Comcast, which may and probably is caching DNS records
> beyond normal TTLs which could cause the difference.  I personally
> always run an Unbound cache server on my mailserver networks to cache
> dns for at least an hour for rbls that I’m not rsyncing, but that
> could cause an issue with Microsoft’s wonderful 10 second MX
> records.  So that’s where I’ve run into this issue, but not often
> enough since I’m just caching for an hour and probably MS expects it.
> 
> So my guess, is probably not anycast, but a caching DNS server that
> is still giving older records.
> 
> Sincerely,
> 
> Eric Tykwinski
> TrueNet, Inc.
> P: 610-429-8300
> 
> > On Dec 7, 2018, at 6:20 PM, Paul Kosinski 
> > wrote:
> > 
> > As some of you may be aware, ever since ClamAV began using
> > Cloudflare, we have seen many occasions when files like daily.cvd
> > were not available to our LAN until well after the DNS TXT record
> > implied they should be.
> > 
> > However, we discovered that these same files *are* available to our
> > Web/email server right away. So what is the difference? The first
> > difference is that our Web server (a VM) is offsite, and is served
> > by the "IAD" Cloudflare complex, whereas our local setup is served
> > by the "BOS" Cloudflare complex.
> > 
> > The second, and likely explanatory difference, is that our local
> > setup is connected via Comcast (a dynamic IP and all that), while
> > our Web server (with its static IP etc.) is almost certainly more
> > directly connected to the Internet as a whole.
> > 
> > The workaround we have adopted is as follows: we installed a
> > "tinyproxy" server on our offsite VM. To ensure it only proxys for
> > us, it listens on the encrypted OpenVPN tunnel we already had in
> > place for FTP uploads etc. Then, instead of directly accessing
> > database.clamav.net, freshclam uses our remote VM as a proxy,so
> > that the cvd files are downloaded indirectly from Cloudflare's IAD
> > server complex (via tinyproxy) rather than directly from
> > Cloudflare's BOS server complex.
> > 
> > Since switching to this workaround a few days ago, we haven't
> > observed any delays: the cvd files are available right away when
> > the DNS TXT query says they should be.
> > 
> > I strongly suspect that Comcast is the culprit in the delays that
> > had plagued us. This is especially suggested by the fact that
> > Cloudflare returns a "Cache-Control:" header similar to:
> > 
> >  Cache-Control: public, max-age=13672
> > 
> > where the max-age value varies, but is often several hours.
> > 
> > In my opinion, for data like ClamAV virus updates, the
> > "Cache-Control:" should specify "no-cache". Can Cloudflare do this
> > for ClamAV?
> > 
> > -
> > 
> > Below is a pair of recent (pre-workaround) log excerpts. They show a
> > delay of over 2.5 hours experienced from BOS (via Comcast) vs no
> > delay from IAD.
> > 
> > Note that the BOS "Date:" timestamp of 16:49:01 GMT *still* shows
> > a "Last-Modified:" timestamp of 06:15:18 GMT, while IAD already
> > shows the up-to-date "Last-Modified:" timestamp of 14:14:30 GMT at
> > the much earlier "Date:" of 14:29:01 GMT!
> > 
> > 
> >  IAD
> > 
> >Date: Sun, 02 Dec 2018 14:09:01 GMT
> >Last-Modified: Sun, 02 Dec 2018 06:15:18 GMT
> >ClamAV-VDB:02 Dec 2018 01-14
> > -0500:25172:2167574:63:13c670e3a525c4fd17bf65524ff05fcd:nwPmlNwUbKmexgT
> > 
> >Date: Sun, 02 Dec 2018 14:29:01 GMT
> >Last-Modified: Sun, 02 Dec 2018 14:14:30 GMT
> >ClamAV-VDB:02 Dec 2018 09-13
> > -0500:25173:2167842:63:ba557f61737b9d4b66acc96f7044b524:3nBAOxo97ssSNZb
> > 
> > 
> >  BOS
> > 
> >Date: Sun, 02 Dec 2018 14:09:01 GMT
> >Last-Modified: Sun, 02 Dec 2018 06:15:18 GMT
>

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

[Eric Tykwinski]

Paul,

Sorry I got it backwards, I thought you were saying the TXT record was 
different which would be effected by DNS caching.
The CloudFlare cache would definitely effect daily.cvd, but updates are new.

Only way I could see you get around it yourself is to create your own cdiff 
program from the source and use the updates, 
which pretty much is using freshclam.

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300

> On Dec 8, 2018, at 10:37 AM, Paul Kosinski  wrote:
> 
> Not sure what DNS caching would have to do with this. As I understand
> "anycast", it happens at the IP address level. An anycast IP address
> gets routed differently depending are where you are -- different
> (regional) routers have different "next hops" for the IP address, and
> it eventually ends up at a "nearby" server. This is in addition to the
> fact that database.clamav.net resolves to 5 different IP addresses (all
> of which are anycast IPs, I would guess).
> 
> The Cloudflare servers, although they have the same IP address(es) seem
> to identify themselves by means of an HTTP header that they return:
> 
>  CF-RAY: 4852e02c35ae5a5c-BOS
>  CF-RAY: 48526af5624356c3-IAD
> 
> Finally, AFAIK, I always get the same result for 
> 
>  "dig TXT current.cvd.clamav.net"
> 
> no matter where I 'dig' (or 'host') from.
> 
> 
> 
> On Fri, 7 Dec 2018 19:27:20 -0500
> Eric Tykwinski  wrote:
> 
>> This is getting rather technical, and probably some of CloudFlare’s
>> secret sauce. It sounds like the anycast DNS that cloudflare hosts
>> isn’t really working, or at least I would assume that they are using
>> anycast.
>> 
>> So you query current.cvd.clamav.net 
>> but are getting different results at IAD and BOS.  Now next is the
>> inclusion of Comcast, which may and probably is caching DNS records
>> beyond normal TTLs which could cause the difference.  I personally
>> always run an Unbound cache server on my mailserver networks to cache
>> dns for at least an hour for rbls that I’m not rsyncing, but that
>> could cause an issue with Microsoft’s wonderful 10 second MX
>> records.  So that’s where I’ve run into this issue, but not often
>> enough since I’m just caching for an hour and probably MS expects it.
>> 
>> So my guess, is probably not anycast, but a caching DNS server that
>> is still giving older records.
>> 
>> Sincerely,
>> 
>> Eric Tykwinski
>> TrueNet, Inc.
>> P: 610-429-8300
>> 
>>> On Dec 7, 2018, at 6:20 PM, Paul Kosinski 
>>> wrote:
>>> 
>>> As some of you may be aware, ever since ClamAV began using
>>> Cloudflare, we have seen many occasions when files like daily.cvd
>>> were not available to our LAN until well after the DNS TXT record
>>> implied they should be.
>>> 
>>> However, we discovered that these same files *are* available to our
>>> Web/email server right away. So what is the difference? The first
>>> difference is that our Web server (a VM) is offsite, and is served
>>> by the "IAD" Cloudflare complex, whereas our local setup is served
>>> by the "BOS" Cloudflare complex.
>>> 
>>> The second, and likely explanatory difference, is that our local
>>> setup is connected via Comcast (a dynamic IP and all that), while
>>> our Web server (with its static IP etc.) is almost certainly more
>>> directly connected to the Internet as a whole.
>>> 
>>> The workaround we have adopted is as follows: we installed a
>>> "tinyproxy" server on our offsite VM. To ensure it only proxys for
>>> us, it listens on the encrypted OpenVPN tunnel we already had in
>>> place for FTP uploads etc. Then, instead of directly accessing
>>> database.clamav.net, freshclam uses our remote VM as a proxy,so
>>> that the cvd files are downloaded indirectly from Cloudflare's IAD
>>> server complex (via tinyproxy) rather than directly from
>>> Cloudflare's BOS server complex.
>>> 
>>> Since switching to this workaround a few days ago, we haven't
>>> observed any delays: the cvd files are available right away when
>>> the DNS TXT query says they should be.
>>> 
>>> I strongly suspect that Comcast is the culprit in the delays that
>>> had plagued us. This is especially suggested by the fact that
>>> Cloudflare returns a "Cache-Control:" header similar to:
>>> 
>>> Cache-Control: public, max-age=13672
>>> 
>>> where the max-age value varies, but is often several hours.
>>> 
>>> In my opinion, for data like ClamAV virus updates, the
>>> "Cache-Control:" should specify "no-cache". Can Cloudflare do this
>>> for ClamAV?
>>> 
>>> -
>>> 
>>> Below is a pair of recent (pre-workaround) log excerpts. They show a
>>> delay of over 2.5 hours experienced from BOS (via Comcast) vs no
>>> delay from IAD.
>>> 
>>> Note that the BOS "Date:" timestamp of 16:49:01 GMT *still* shows
>>> a "Last-Modified:" timestamp of 06:15:18 GMT, while IAD already
>>> shows the up-to-date "Last-Modified:" timestamp of 14:14:30 GMT at
>>> the much earlier "Date:" of 14:29:01 GMT!
>>> 
>>> 

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

[J.R.]

I've kind of been reading this thread about the delay at one location
vs the other.

Maybe I missed it, but I don't seem to recall which DNS servers you
were querying. I remember you saying the one location you were having
the issues was Comcast as the ISP, but were you always using the
Comcast DNS or did you try others like 1.1.1.1 or 8.8.8.8 ?

Or was the DNS saying there was a newer version but when you queried
cloudflare it was reporting differently?
___
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

[Eric Tykwinski]

J.R.

You are falling into the same trap I followed.  The txt record is:
 current.cvd.clamav.net.1749IN  TXT 
"0.101.0:58:25189:1544315340:1:63:48210:327"

But host headers is what he’s looking at:
telnet database.clamav.net 80
Trying 104.16.185.138...
Connected to database.clamav.net.cdn.cloudflare.net.
Escape character is '^]'.
GET /daily.cvd HTTP/1.1
host: database.clamav.net

HTTP/1.1 200 OK
Date: Sun, 09 Dec 2018 01:18:51 GMT
Content-Type: application/octet-stream
Content-Length: 53110330
Connection: keep-alive
Set-Cookie: __cfduid=ddc4d2ab2a13638c99a90bb14c12128971544318331; expires=Mon, 
09-Dec-19 01:18:51 GMT; path=/; domain=.clamav.net; HttpOnly
Last-Modified: Sat, 08 Dec 2018 18:18:00 GMT
ETag: "5c0c0ad8-32a663a"
Expires: Sun, 09 Dec 2018 05:05:51 GMT
Cache-Control: public, max-age=13620
CF-Cache-Status: HIT
Accept-Ranges: bytes
Server: cloudflare
CF-RAY: 4863a3a9553bc5d2-EWR

ClamAV-VDB:08 Dec 2018 13-18 
-0500:25189:2177974:63:2e2e28a4556e83e2df68c40fa61566d4:nWqDCF65xA9fMhiKYOtZhH8Up6lAHLrl6VyCrXRAXCB7aMf7WqSPrwMz/YHhdgKSNjxGiL8Z2ORQ2aPm23KwqwyJUpOZv94+soWx+NibPlKBPJ6/ZAt9Z5UrhgDbgz0IVQsHX998ZjBE6NY6xtqfzboOPNKyeFINLeAUL5hSpzj:neo:1544293134

So daily.cvd is being cached on cloudflare for the first update and you might 
need to be running a freshclam right after a new install since it’s out of date 
due to caching on cloudflare’s server.  

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300

> On Dec 8, 2018, at 7:30 PM, J.R.  wrote:
> 
> I've kind of been reading this thread about the delay at one location
> vs the other.
> 
> Maybe I missed it, but I don't seem to recall which DNS servers you
> were querying. I remember you saying the one location you were having
> the issues was Comcast as the ISP, but were you always using the
> Comcast DNS or did you try others like 1.1.1.1 or 8.8.8.8 ?
> 
> Or was the DNS saying there was a newer version but when you queried
> cloudflare it was reporting differently?
> ___
> 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)]

Not sure what you’re saying here.  Are you saying that the daily on the cache 
is out of date?

Sent from my  iPhone

> On Dec 8, 2018, at 20:30, Eric Tykwinski  wrote:
> 
> J.R.
> 
> You are falling into the same trap I followed.  The txt record is:
> current.cvd.clamav.net.1749INTXT
> "0.101.0:58:25189:1544315340:1:63:48210:327"
> 
> But host headers is what he’s looking at:
> telnet database.clamav.net 80
> Trying 104.16.185.138...
> Connected to database.clamav.net.cdn.cloudflare.net.
> Escape character is '^]'.
> GET /daily.cvd HTTP/1.1
> host: database.clamav.net
> 
> HTTP/1.1 200 OK
> Date: Sun, 09 Dec 2018 01:18:51 GMT
> Content-Type: application/octet-stream
> Content-Length: 53110330
> Connection: keep-alive
> Set-Cookie: __cfduid=ddc4d2ab2a13638c99a90bb14c12128971544318331; 
> expires=Mon, 09-Dec-19 01:18:51 GMT; path=/; domain=.clamav.net; HttpOnly
> Last-Modified: Sat, 08 Dec 2018 18:18:00 GMT
> ETag: "5c0c0ad8-32a663a"
> Expires: Sun, 09 Dec 2018 05:05:51 GMT
> Cache-Control: public, max-age=13620
> CF-Cache-Status: HIT
> Accept-Ranges: bytes
> Server: cloudflare
> CF-RAY: 4863a3a9553bc5d2-EWR
> 
> ClamAV-VDB:08 Dec 2018 13-18 
> -0500:25189:2177974:63:2e2e28a4556e83e2df68c40fa61566d4:nWqDCF65xA9fMhiKYOtZhH8Up6lAHLrl6VyCrXRAXCB7aMf7WqSPrwMz/YHhdgKSNjxGiL8Z2ORQ2aPm23KwqwyJUpOZv94+soWx+NibPlKBPJ6/ZAt9Z5UrhgDbgz0IVQsHX998ZjBE6NY6xtqfzboOPNKyeFINLeAUL5hSpzj:neo:1544293134
> 
> So daily.cvd is being cached on cloudflare for the first update and you might 
> need to be running a freshclam right after a new install since it’s out of 
> date due to caching on cloudflare’s server.  
> 
> Sincerely,
> 
> Eric Tykwinski
> TrueNet, Inc.
> P: 610-429-8300
> 
>> On Dec 8, 2018, at 7:30 PM, J.R.  wrote:
>> 
>> I've kind of been reading this thread about the delay at one location
>> vs the other.
>> 
>> Maybe I missed it, but I don't seem to recall which DNS servers you
>> were querying. I remember you saying the one location you were having
>> the issues was Comcast as the ISP, but were you always using the
>> Comcast DNS or did you try others like 1.1.1.1 or 8.8.8.8 ?
>> 
>> Or was the DNS saying there was a newer version but when you queried
>> cloudflare it was reporting differently?
>> ___
>> 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


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