Mailing List Archive

1 2 3  View All
Re: Idea for more timely virusdb updates [ In reply to ]
Jeremy Kitchen wrote:
> or scrap the whole idea all together :)

Maybe the best thing written on the subject today! ;-) j/k

But really, what's the problem? Shouldn't "big time folks" complain to
the commercial companies to whom they pay for service and still they got
updates later than Clam? Instead hundreds of mails are written here with
one "solution" more far out than the other.

Please, I *think* you might have caught the attention of the developers
by now so please let them think about this for a moment. They still beat
everyone else so I just want to say thank you. Everything works great!
In combination with MailScanner which checks inside zip files and blocks
executables I stopped all the viruses even before Clam was updated. From
what I have seen from reading this list for some time many of you seem
to rely to heavily on too few layers of protections. Maybe that's why
you "must" have the updates immediately with no regard to server load or
maybe I missed the solution that took care of that one too in the flood
of mail. Premium servers for a fee is the best solution I have seen so far.

No offence meant to anyone in particular.

--
/Peter Bonivart

--Unix lovers do it in the Sun

Sun Fire V210, Solaris 9, Sendmail 8.12.10, MailScanner 4.32.5,
SpamAssassin 2.63 + DCC 1.2.50, ClamAV 0.75.1 + GMP 4.1.2, Vispan 1.4


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: Idea for more timely virusdb updates [ In reply to ]
Jeremy Kitchen wrote:
> On Tuesday 10 August 2004 02:41 pm, Damian Menscher wrote:
> [.snip: using a program delivery to process update mailing list mails]
>
>>With sendmail, you could add to /etc/aliases something like:
>>clamav-updates | sigtool --add
>
>
> that's the ticket.
>
>

And a cool little DOS tool. Nothing like a well-known email address for a little
fun having. I imagine the blackhats will slam that rather quickly.

dp


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: Idea for more timely virusdb updates [ In reply to ]
OK, here's my pitch

I like the DNS idea as a way to push out just the version number of the
update. This "pattern serial number" would be the current version of the
CVD file.

A record like this in tinydns:

'dbversion.clamav.net:447:600

would create a DNS TXT record for "dbversion.clamav.net" with a value of
"447" with a TTL of 600 sec (10 minutes). I see no point in any more
information being recorded.

If freshclam were to initially do that DNS lookup, it could afford to look
every 10 minutes instead of hourly, and would dramatically cut down on the
amount of HTTP (or any other TCP) transactions required.

I think all the comments about using SMTP or NNTP suffer the same problem as
HTTP - they are no where near as fast or as natively "multicast" as DNS is -
oh yeah - and it's UDP too. DNS natively "shares the load", whereas all
other "load sharing" solutions would have to be created.

So I'd envisage freshclam doing the DNS lookup, and if the "pattern number"
TXT record returned is *different* (not smaller! DNS cache poisoning can
affect this solution, so just choose DIFFERENT) than the current "pattern
number", then it should check for an update. This has the advantage that it
could just be a new bit of code added in front of the existing freshclam
code.

The TTL > 0 allows you to even cut down the load on the primary DNS servers.
The ClamAV team should make a "policy" saying people aren't allowed to check
for updates more often than every "TTL" seconds and this within freshclam
would enforce it.

Just my 2c worth

--
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: Idea for more timely virusdb updates [ In reply to ]
In a perfect world, wouldn't this be the ultimate application for say,
multicast? Just keep casting the database over and over, when it
changes, you instantly have it! ;-)

--
Robert Blayzor, BOFH
INOC, LLC
rblayzor@inoc.net
PGP: http://www.inoc.net/~dev/
Key fingerprint = 1E02 DABE F989 BC03 3DF5 0E93 8D02 9D0B CB1A A7B0

Press Ctrl-Alt-Del now for IQ test.


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
RE: Idea for more timely virusdb updates [ In reply to ]
> The mirror page talkes about the need for mirrors, about
> exponential growth,
> and how at least a 10mbit pipe is needed to host a mirror. It puts March
> 2004 traffic at about 120gig/month
>

I think I read it differently... I thought it was 120GB / month per mirror
(at that point in time there were 11 mirrors!)

QUOTE (http://www.clamav.net/doc/mirrors/clamav-mirror-howto.txt)
Without mirrors, the traffic on our main site was
100GB/month (May 2003).

On Feb 2004 the traffic on each mirror (11 in total)
reached 120GB/month.
END QUOTE

Not sure if I read it wrong, but that would put total consumption about 1320
GB - makes it more urgent doesn't it?

Unfortunately the round robin - no limits nature makes the "entry price" for
people who want to help too high for some. I wonder in the short term if
there is a way to create a lower % hit mirror which could say take 10% of
the normal average...

at 12GB / month there might be more takers

m/



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
RE: Idea for more timely virusdb updates [ In reply to ]
> I've already mentioned this jokingly, but I was half serious: I think
> setting up a bittorrent would solve a lot of the bandwidth problems.
>

Been playing with that a bit recently - the more I think about it, the more
I like it... saw a website that has built a custom tracker to manage
leeches, and prevent people (regardless of client) from sponging without
contributing...

The old way could remain, for offline / intermittantly or heavily firewalled
users...

The addition of DNS version management could reduce overhead bandwidth that
occurs during useless polls...

The new way could provide higher frequency updates for those willing to
share and contribute some bytes.

m/



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: Idea for more timely virusdb updates [ In reply to ]
Am Mittwoch, 11. August 2004 04:56 schrieb Robert Blayzor:

Hi,

> In a perfect world, wouldn't this be the ultimate application for say,
> multicast?

No, multicast is not the most efficient solution and does no caching. Honestly
imho the DNS approach is the most feasable and the most efficient solution as
it provides incoherent caching uses udp and reuses a widly available
infrastructure.

Regards,
-- martin

Dipl.-Phys. Martin Konold

e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Nobelstrasse 15, 70569 Stuttgart, Germany
fon: 0711 67400963, fax: 0711 67400959
email: martin.konold@erfrakon.de


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
RE: Idea for more timely virusdb updates [ In reply to ]
Daniel J McDonald wrote:

> That's one of the things that seems to be driving the size of
> daily.cvd up - updating main.cvd entails a massive
> distribution of files to the world.

Current main.cvd = 1103636 bytes, last updated on July 8
Current daily.cvd = 156470 bytes

A bit of mental arithmetic suggests thatdaily.cvd grows by about 5KB per
day.

A few sums in my head suggest that total download savings in a month if
main.cvd was updated fortnightly would be around 200KB (circa 3100KB
total download instead of 3300KB), a virtually insignificant difference.

> Perhaps a tiered approach to the update files, with main.cvd,
> monthly.cvd, weekly.cvd, daily.cvd, and hot.cvd

> The advantage there is that the really big update could be
> distributed very seldom - perhaps only with new code (the
> code generally has to be upgraded every few months to deal
> with a new threat anyway).

Big updates often remove false positives, improve detections of existing
viruses, so might still need monthly (or more frequent) updating.

> If you had overlapping signatures between the files, you
> could add a fuzzy-factor into freshclam that it might not
> bring down the latest weekly/monthly if the other files
> overlap completely. That would distribute the load on the
> freshclam servers for the larger updates, and there would
> just be the very small daily.cvd (and perhaps hot.cvd) downloads.

If we could use incremental (or, more correctly, differential) updates
which effectively create a new main.cvd then we could have a large
reduction in the load on the download servers. However, we then have
the problem of ensuring that main.cvd remains consistent.

> I like the idea of using DNS to signal the change - maybe
> just for hot.cvd. so, whenever a major virus breakout
> occurs, the new sig would be added to hot.cvd and the DNS
> TXT record changed. 10,000 users pulling down a 2-3K file is
> not terribly hard for a server with decent bandwidth

I've known DNS servers to completely ignore TTL figures and cache stuff
which should have expired, so this might not be reliable.

Cheers,

Phil
----
Phil Randal
Network Engineer
Herefordshire Council
Hereford, UK


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: Idea for more timely virusdb updates [ In reply to ]
On Aug 10, 2004, at 2:30 PM, Jeremy Kitchen wrote:

> On Tuesday 10 August 2004 12:23 pm, Damian Menscher wrote:
>> The gpg-signature prevents spoofing. And the sequence numbers
>> keep everyone current. The major problems I see are getting clamd to
>> recognize a message targeted for it, and the obvious problems of DoS
>> attacks (someone sending spoofed messages that would suck CPU time
>> decoding the gpg signature).
>
> yes, that's an unfortunate problem with this idea, however, if you
> used, as I
> stated, a special address that uses program delivery, you'd have to
> hack the
> listserver to get everyone's 'subscription' address to be able to do
> this.

Instead of having this piggyback on email, I was thinking more along
the line of a separate protocol just *modeled* after email. Separate
port, separate server daemon for it...maybe it would lessen the chances
of your updates getting filtered by spam filters and/or targeted for
probes and overflow attacks in the process.

That way it isn't hacking the MTAs out there to do work that isn't
meant or related to them...never liked the idea of bending programs
backwards to tack on added functionality. Seems to be another vector
for bug creep :-)


>> [.I haven't given up on DNS updates yet, but it's hard to come up with
>> a
>> clean way to distribute >256 bytes of data that way, which means even
>> single rules don't always fit.]
>
> I wouldn't distribute the rule in DNS, however, a timestamp of sorts
> in dns
> isn't a bad idea.

While DNS is an interesting idea, I'm worried more about what kind of
bugs and glitches this is going to uncover in the process (or what kind
of attacks would be crafted should this idea catches on.) Let's say
the idea does become popular, and clam and other programs out there
start taking advantage of it...I don't know about all of you, but I
didn't set up a DNS server on a system meant for constant hits from
other sources querying it; it's just a little system that can handle
the load of a small network and that's pretty much it :-) And what
about systems that restrict querying to certain IPs? If a service
starts getting abused, that tends to be when (clueful) admins start
taking steps to lock things down; many places with NTP servers, for
example, will host a "public" site until too many people start hitting
and if it starts to become a burden, the time server suddenly
disappears. :-(

-Bart



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: Idea for more timely virusdb updates [ In reply to ]
Martin Konold wrote:

> No, multicast is not the most efficient solution and does no caching. Honestly
> imho the DNS approach is the most feasable and the most efficient solution as
> it provides incoherent caching uses udp and reuses a widly available
> infrastructure.

Why would you need caching? Especially when using PIM sparse.

--
Robert Blayzor, BOFH
INOC, LLC
rblayzor@inoc.net
PGP: http://www.inoc.net/~dev/
Key fingerprint = 1E02 DABE F989 BC03 3DF5 0E93 8D02 9D0B CB1A A7B0

There are two major products that come out of Berkeley: LSD and UNIX. We
don't believe this to be a coincidence. - Jeremy S. Anderson


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
RE: Idea for more timely virusdb updates [ In reply to ]
> -----Original Message-----
> From: clamav-users-admin@lists.sourceforge.net
> [mailto:clamav-users-admin@lists.sourceforge.net]On Behalf Of Dennis
> Peterson
>
>
> Jeremy Kitchen wrote:
> > On Tuesday 10 August 2004 02:41 pm, Damian Menscher wrote:
> > [.snip: using a program delivery to process update mailing list mails]
> >
> >>With sendmail, you could add to /etc/aliases something like:
> >>clamav-updates | sigtool --add
> >
> >
> > that's the ticket.
> >
> >
>
> And a cool little DOS tool. Nothing like a well-known email
> address for a little
> fun having. I imagine the blackhats will slam that rather quickly.
>

The list can have a simple algorithm to filter any 'easy' or mnemotenic
email address thats trying to subscribe. That way we can reduce the problem.

In concern of cvd corruption because a malformed patches, I think that the
updater could backup some old states of the sig file in order to have the
posibility to downgrade without downloading sigs again (manually or
something).
In any case, the patch can always have a 'before MD5' and an 'after MD5',
just to be sure.

Another idea to save bandwidth (in a pull fashion) could be to download
instead of:
daily.cvd
something like:
daily.cvd?myver=XXX&MD5=XXXXXXXXXXXXXXXXXXXXXXXXXX

Were _myver_ and _MD5_ are my sigfile's version and it's MD5 respectively.
The server could make a patch to the last version in real time and send it,
instead of sending the 'big' file. The realtime patch could be done cat'ing
all patches needed together or already having created all the respective
daily_fromN_toCURRENT.cvd patches.
Could also be implemented directly into main.cvd.

Brainstorming is great... as long as I don't have to code resulting ideas ;)

Thanks to all for this great bits.

-Samuel



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: Idea for more timely virusdb updates [ In reply to ]
Christopher X. Candreva wrote the following on 08/10/2004 07:40 PM :

> If people can't check for database updates more often than once an hour,
>
>then there is a pressing need.
>
>The mirror page talkes about the need for mirrors, about exponential growth,
>and how at least a 10mbit pipe is needed to host a mirror. It puts March
>2004 traffic at about 120gig/month
>
>

The bandwidth used on our mirrors (clamav.inet6.fr) as lowered since
then mainly thanks to the ability of new clients to abort the
transmission of a file when it is the same version as the one they
already have.

The ideal setup would be to push updates instead of clients polling
them. It would requires a separate architecture though (HTTP mirrors
can't push things).

Since some time I am thinking of a bittorrent approach too. Bittorrent
is quite efficient at distributing files and there are implementations
allowing multiple trackers to distribute the remaining server-side load.
If I'm not mistaken, there's only one thing to add :
querying for the latest available torrent which must be signed by the db
authors : DNS would be great for this indeed (hash sigs prevent cache
poisoning and thus distribution of invalid db, but not DoS).

Lionel.


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: Idea for more timely virusdb updates [ In reply to ]
Am Mittwoch, 11. August 2004 13:53 schrieb Bart Silverstrim:

Hi Bart,

> the idea does become popular, and clam and other programs out there
> start taking advantage of it

DNS was developed exactly for this kind of purpose.

> ...I don't know about all of you, but I
> didn't set up a DNS server on a system meant for constant hits from
> other sources querying it

Sorry, I dont want to sound impolite but please try to become familiar how DNS
works in todays internet.

> ; it's just a little system that can handle
> the load of a small network and that's pretty much it :-)

Your little DNS server will only get queries from you very own clamav
installation but not from _anyone_ else.

> And what
> about systems that restrict querying to certain IPs?

?? This makes no sense. If you system is able to do http with using fqdn then
it is also able to use the DNS.

> If a service
> starts getting abused, that tends to be when (clueful) admins start
> taking steps to lock things down; many places with NTP servers, for
> example, will host a "public" site until too many people start hitting
> and if it starts to become a burden, the time server suddenly
> disappears. :-(

Typically the DNS load will be put on the ISPs. The ISPs prever _very_ much
people using the DNS which is an incoherent or loosly coherent caching and
distributed database to permanent polling, multicast or pushing.

Funny enough: The protocol ideas you are proposeing are putting _more_ load on
the DNS(*) than the direct DNS idea.

(*) it is save to assume that your protocol ideas don't use static ip numbers
but use DNS to do gethostbyname() resolving.

Regards,
-- martin

Dipl.-Phys. Martin Konold

e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Nobelstrasse 15, 70569 Stuttgart, Germany
fon: 0711 67400963, fax: 0711 67400959
email: martin.konold@erfrakon.de


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: Idea for more timely virusdb updates [ In reply to ]
On Aug 11, 2004, at 10:32 AM, Martin Konold wrote:

> Am Mittwoch, 11. August 2004 13:53 schrieb Bart Silverstrim:
>
> Hi Bart,
>
>> the idea does become popular, and clam and other programs out there
>> start taking advantage of it
>
> DNS was developed exactly for this kind of purpose.

Storing non-DNS related information for retrieval? As I understand the
proposition (and the original lecture that this idea was based on),
it's was for hiding information in a very small records area of DNS for
propogating information...I don't think the designers for DNS had
spreading AV signatures (or files or other things that have been
proposed, non-Clam related) in mind at the time. Also I was worried
about the fact that DNS servers usually got traffic for updates from
peers and client/server lookups, not spreading files...that would boost
their hits and bandwidth.

>> ...I don't know about all of you, but I
>> didn't set up a DNS server on a system meant for constant hits from
>> other sources querying it
>
> Sorry, I dont want to sound impolite but please try to become familiar
> how DNS
> works in todays internet.

Prefacing it with not wanting to sound impolite still makes it sound
impolite but that's okay :-)

I'm not a DNS expert by any means. It's been five years or so since I
set up a bare linux system as an authoritative DNS server, other setups
I've made were all in-house caching servers. I'll make no claim to
knowing how things work exactly or the pitfalls of trying this out, or
the effect it would have on the servers.

But I *have* had enough experience to say that if I have these
questions, chances are someone else on the lists has them too,
vocalizing them or not...and they'll hopefully get an education from
the answers I get as the result of my chiming in :-)

>> ; it's just a little system that can handle
>> the load of a small network and that's pretty much it :-)
>
> Your little DNS server will only get queries from you very own clamav
> installation but not from _anyone_ else.

The proposal is just to have a few DNS servers, the authoritative ones,
seeded with the info then? Others would just cache it? Duh. Makes
sense.

>> And what
>> about systems that restrict querying to certain IPs?
>
> ?? This makes no sense. If you system is able to do http with using
> fqdn then
> it is also able to use the DNS.

I think at the time I was thinking about DNS servers updating from
peers, distributing the load of the records that are spread piecemeal.

> Funny enough: The protocol ideas you are proposeing are putting _more_
> load on
> the DNS(*) than the direct DNS idea.
>
> (*) it is save to assume that your protocol ideas don't use static ip
> numbers
> but use DNS to do gethostbyname() resolving.

You would be correct; it would be the load made by any listserv though.
any spreading of an "email like" server's load would increase lookups
(unless assisted by local caches heavily).

It's not necessarily the load on the server I think I was worrying
about, per se...it's trying to shoehorn the protocol to do more than it
was supposed to. It's probably a misunderstanding of the idea for
spreading the information through DNS, but I would think that the DNS
idea would hit a wall or block that would be imposed by the
restrictions of DNS itself and the way it works, so a new mechanism
would have to supplement it or some other clever hack. I would think
that it would be better to start a propagation idea from scratch rather
than a neat idea (I'm not trying to disregard it...heck, I'm probably
missing something obvious and am worrying about a non-issue) for
extending a protocol meant for task A being extended to also be able to
do task B.

-Bart



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: Idea for more timely virusdb updates [ In reply to ]
On Wed, 11 Aug 2004, Lionel Bouton wrote:

> Since some time I am thinking of a bittorrent approach too. Bittorrent
> is quite efficient at distributing files and there are implementations
> allowing multiple trackers to distribute the remaining server-side load.

Please take this as a question rather than a criticism of the approach:

My experience with bittorrent has been with downloading huge things,
like Fedora. It tends to start up really slowly (since it has to find
peers) and then speed up. But the speedup doesn't occur until several
megs have been downloaded. If we're only sending a 1-meg main.cvd, then
wouldn't bittorrent lose its advantage to all the overhead of finding
peers?


With regard to all the other ideas: Please remember to keep this
*simple*. Here's where I, IMHO, think we stand:

Opening a new port on a mailserver so updates can be pushed to it is a
BAD idea. As a sysadmin, I would not allow such a thing on my
production machines. It creates a huge security risk, since now you
have one more opening to a remote root vulnerability.

The idea of DNS sounds really good, but it doesn't appear we can fit all
the data there. And putting just a version number there appears to make
things worse, since it will just make everyone hit the mirrors at the
same time. If we can somehow distribute signatures that way it would be
nice, but it just doesn't seem practical.

I'm really starting to like the idea of a mailing list that can have
dedicated (and random for each site) subscription addresses and pipe the
list straight into "sigtool --add". It means we'd have to find someone
to host the list, but that's probably no more difficult than finding
someone to host a mirror. Presumably there could even be multiple
"mirrors" sending the list, to improve speed (taking an idea from
spammers who use open relays to do the hard part).

One thing to add to the mailing list approach: there needs to be some
sort of "heartbeat" or "dead man's switch" -- a way to know that the
mailing list is functional, but there are no needed updates, rather than
that the mailing list has broken. I suppose this might be a use for
that latest-db-version.clamav.net idea.

Damian Menscher
--
-=#| Physics Grad Student & SysAdmin @ U Illinois Urbana-Champaign |#=-
-=#| 488 LLP, 1110 W. Green St, Urbana, IL 61801 Ofc:(217)333-0038 |#=-
-=#| 4602 Beckman, VMIL/MS, Imaging Technology Group:(217)244-3074 |#=-
-=#| <menscher@uiuc.edu> www.uiuc.edu/~menscher/ Fax:(217)333-9819 |#=-
-=#| The above opinions are not necessarily those of my employers. |#=-


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: Idea for more timely virusdb updates [ In reply to ]
Am Mittwoch, 11. August 2004 14:47 schrieb Robert Blayzor:

Hi,

> > No, multicast is not the most efficient solution and does no caching.
> > Honestly imho the DNS approach is the most feasable and the most
> > efficient solution as it provides incoherent caching uses udp and reuses
> > a widly available infrastructure.
>
> Why would you need caching?

PIM sparse helps in some situations but it put extra load on the routers. I
like the fact the PIM sparse is a "request-only service but still imho a pull
is better than a push approach.

For enterprise use and its security policies using http for the download is
most appropriate especially when using caching upstream http proxies.

> Especially when using PIM sparse.

Regards,
-- martin

Dipl.-Phys. Martin Konold

e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Nobelstrasse 15, 70569 Stuttgart, Germany
fon: 0711 67400963, fax: 0711 67400959
email: martin.konold@erfrakon.de


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: Idea for more timely virusdb updates [ In reply to ]
Damian Menscher wrote the following on 08/11/2004 04:40 PM :

>On Wed, 11 Aug 2004, Lionel Bouton wrote:
>
>
>
>>Since some time I am thinking of a bittorrent approach too. Bittorrent
>>is quite efficient at distributing files and there are implementations
>>allowing multiple trackers to distribute the remaining server-side load.
>>
>>
>
>Please take this as a question rather than a criticism of the approach:
>
>My experience with bittorrent has been with downloading huge things,
>like Fedora. It tends to start up really slowly (since it has to find
>peers) and then speed up. But the speedup doesn't occur until several
>megs have been downloaded. If we're only sending a 1-meg main.cvd, then
>wouldn't bittorrent lose its advantage to all the overhead of finding
>peers?
>
>
>

It depends on the torrents you download. Some starts really quickly.
From my experience it really depends on how much clients are really
available to upload files and the ratio of good/bad clients known by the
tracker : when numerous clients stop distributing content after
finishing a download, some (and sometimes most of the) clients the
tracker send you are now unavailable and you then start having timeouts
and asking other clients to the tracker. In a more controlled
environnement where the client behaviour will be hard-coded in a
hypothetical freshclam-torrent to serve the last two db files and
properly warn the trackers when they stop distributing contents, you
most probably won't experience such problems.
Remember that bittorrent was designed specifically to handle the very
same problem we are discussing, the quality of some popular
implementations may damage the efficiency of the protocol, but in the
clamav context we don't have to deal with this problem.

>With regard to all the other ideas: Please remember to keep this
>*simple*. Here's where I, IMHO, think we stand:
>
>Opening a new port on a mailserver so updates can be pushed to it is a
>BAD idea. As a sysadmin, I would not allow such a thing on my
>production machines. It creates a huge security risk, since now you
>have one more opening to a remote root vulnerability.
>
>

The freshclam process is less risky because tricking freshclam into
connecting to an arbitrary system requires injecting DNS entries
somewhere, controlling the routing process or even injecting content in
TCP conversations which all are more complex techniques than exploiting
a buffer overflow on a server for example. But the problem is not really
in opening ports or not but in controlling the quality of the code you
run. TCP and DNS are not secure so freshclam must add its security layer
above, theoritically it doesn't really matter if it is running as a TCP
client or server.

>The idea of DNS sounds really good, but it doesn't appear we can fit all
>the data there. And putting just a version number there appears to make
>things worse, since it will just make everyone hit the mirrors at the
>same time.
>

Using DNS doesn't mean the freshclam processes will all be waking up at
the same time to query the DNS entry. They may use shorter delays than
the current 1 or 2 hours, but even with one second delay, the queries
leaving the local DNS servers in the recursive process would be
distributed on a TTL-wide period. The TTL being controlled by the
authoritative servers.

If there's a problem of bandwidth/load on the mirrors, then move it away
from them by designing a new (parallel ?) distribution mechanism or
throw more mirrors on it. But as I said I'm not yet convinced there's a
real problem. Shorting the delay from db update to db install on each
mail server is good, but don't forget that 1 hour is already low
compared to the time between the first virus appearance and its
signature addition in the database. We will never eliminate that delay
and must do with it.



> If we can somehow distribute signatures that way it would be
>nice, but it just doesn't seem practical.
>
>I'm really starting to like the idea of a mailing list that can have
>dedicated (and random for each site) subscription addresses and pipe the
>list straight into "sigtool --add". It means we'd have to find someone
>to host the list, but that's probably no more difficult than finding
>someone to host a mirror.
>

Are you kidding ? Our mirrors have seen more than 120000 clamav clients
last month and we only see a *part* of the *european* clients. Mirrors
handled with round-robin DNS are fairly easy to setup, but sending
120000 mails for each db update can very well end up burying one mail
server under the load.

> Presumably there could even be multiple
>"mirrors" sending the list, to improve speed (taking an idea from
>spammers who use open relays to do the hard part).
>
>

Using spammers' techniques could help but at quite a cost in complexity
and in the end I don't think it would be practical for the end-users.


--
Lionel Bouton - inet6
---------------------------------------------------------------------
o Siege social: 51, rue de Verdun - 92158 Suresnes
/ _ __ _ Acces Bureaux: 33 rue Benoit Malon - 92150 Suresnes
/ /\ /_ / /_ France
\/ \/_ / /_/ Tel. +33 (0) 1 41 44 85 36
Inetsys S.A. Fax +33 (0) 1 46 97 20 10




-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: Idea for more timely virusdb updates [ In reply to ]
Lionel Bouton wanted us to know:

>Since some time I am thinking of a bittorrent approach too. Bittorrent
>is quite efficient at distributing files and there are implementations
>allowing multiple trackers to distribute the remaining server-side load.

There's a libbt library written in C that could accomplish this without
having to spawn a scripting language interpreter (eg python).

>If I'm not mistaken, there's only one thing to add :
>querying for the latest available torrent which must be signed by the db
>authors : DNS would be great for this indeed (hash sigs prevent cache
>poisoning and thus distribution of invalid db, but not DoS).

I like this idea, but want to study it a little more as I'm afraid of
what will happen when a virus comes out that DOS's clamav nameservers
(thus preventing or making much more difficult the proliferation of
signatures to detect it). I think in such a case though, a fallback of
"poll for it anyway" would be sufficient but only if DNS A records are
still responsive.
--
Regards... Todd
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. --Benjamin Franklin
Linux kernel 2.6.3-15mdkenterprise 2 users, load average: 0.14, 0.06, 0.02


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
RE: Idea for more timely virusdb updates [ In reply to ]
> Opening another port is simply no option for any serious
> enterprise use. There
> is simply no way to open another port in the firewall. In addition I am
> confident that IANA will not allow to reserve a fixed port number
> for this
> service. After all port numbers are a limited resource with todays IPv4
> networks.

bittorrent doesn't rely on a fixed port - it doesn't need one.

If I understand it right, seeders (people with full copies) and peers
(people with partial downloads) register their ports with the tracker, and
if shutdown properly, de-register themselves.

The problem with slow starts DEFINITELY has something to do with seeders and
peers not deregistering themselves (I see it in logs) and have seen FAQ's on
web sites hosting torrent files to this effect.

With a closed loop distribution system with a custom client that guaranteed
a 10X ratio and then cleanly deregistered itself, we would have a very
powerful distribution system.

Might even make a project on it's own.

m/



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: Idea for more timely virusdb updates [ In reply to ]
Am Wednesday 11 August 2004 16:19 schrieb Bart Silverstrim:

Hi Bart,

> > DNS was developed exactly for this kind of purpose.
>
> Storing non-DNS related information for retrieval? As I understand the
> proposition (and the original lecture that this idea was based on),
> it's was for hiding information in a very small records area of DNS for
> propogating information...I don't think the designers for DNS had
> spreading AV signatures (or files or other things that have been
> proposed, non-Clam related) in mind at the time.

Please be aware of the fact that I don't think that DNS is the correct tool to
distribute files but for distributing something like a serial number it fits
perfectly.

The actual download of the data has to be done outside of the DNS system.

> Also I was worried
> about the fact that DNS servers usually got traffic for updates from
> peers and client/server lookups, not spreading files...that would boost
> their hits and bandwidth.

I am afraid this is a missunderstanding as I am not advocating to distribute
files via the dns but only a serial number.

> vocalizing them or not...and they'll hopefully get an education from
> the answers I get as the result of my chiming in :-)

I think this is totally fine :-)

> was supposed to. It's probably a misunderstanding of the idea for
> spreading the information through DNS, but I would think that the DNS
> idea would hit a wall or block that would be imposed by the
> restrictions of DNS itself and the way it works, so a new mechanism
> would have to supplement it or some other clever hack. I would think
> that it would be better to start a propagation idea from scratch rather
> than a neat idea (I'm not trying to disregard it...heck, I'm probably
> missing something obvious and am worrying about a non-issue) for
> extending a protocol meant for task A being extended to also be able to
> do task B.

In short: Using DNS for spreading _small_ pieces of information which
typically have some reasonable TTL (time to live) and which can deal with the
loose coherency of DNS is totally fine.

Abusing the DNS to directly transfer files etc is not appropriate as the DNS
infrastructure is not ready for such kind of "abuse".

Regards,
-- martin

Dipl.-Phys. Martin Konold

e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Nobelstrasse 15, 70569 Stuttgart, Germany
fon: 0711 67400963, fax: 0711 67400959
email: martin.konold@erfrakon.de


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: Idea for more timely virusdb updates [ In reply to ]
Am Wednesday 11 August 2004 16:40 schrieb Damian Menscher:

Hi,

> like Fedora. It tends to start up really slowly (since it has to find
> peers) and then speed up. But the speedup doesn't occur until several
> megs have been downloaded. If we're only sending a 1-meg main.cvd, then
> wouldn't bittorrent lose its advantage to all the overhead of finding
> peers?

IMHO this is a very valid concern.

> With regard to all the other ideas: Please remember to keep this
> *simple*. Here's where I, IMHO, think we stand:
>
> Opening a new port on a mailserver so updates can be pushed to it is a
> BAD idea. As a sysadmin, I would not allow such a thing on my
> production machines. It creates a huge security risk, since now you
> have one more opening to a remote root vulnerability.

Opening another port is simply no option for any serious enterprise use. There
is simply no way to open another port in the firewall. In addition I am
confident that IANA will not allow to reserve a fixed port number for this
service. After all port numbers are a limited resource with todays IPv4
networks.

> The idea of DNS sounds really good, but it doesn't appear we can fit all
> the data there.

Yes.

> And putting just a version number there appears to make
> things worse, since it will just make everyone hit the mirrors at the
> same time.

This is not really such a big problem as the DNS is still no push but a pull
service and the incoherency of the DNS leads to a smoothing effect.

> If we can somehow distribute signatures that way it would be
> nice, but it just doesn't seem practical.

I agree with you.

> I'm really starting to like the idea of a mailing list that can have

This is a very bad idea. As someone who is used to run _very_ big mailing
lists I can tell you that the resources to run a _big_ mailing list are 3 or
even 4 magnitudes bigger than a simple webserver offering the very same
single file to everyone interested via HTTP GET.

Offering this file e.g. 1MB via http get allows very easy to saturate any
backbone with useful data _without_ the need to handle DNS lookups,
generating an email, try delivery (multiple packages back and forth) and then
finally having about 3-5 percent of the connection be failures -->
retries,....

Using the very same hw resources (cpu, memory and bandwidth) with http get
allows for much more (think about a factor of 100 or 1000) information be
spread within a timeinterval.

Things to think about:
- Effort required to create a mail body
- overhead of 7bit email encoding
- effort required to do the email envelope
- Effort for queuing many emails (much copying on the server)
- No caching on the intermediate servers (only proxying)
- Handling bounces etc.
- Doing many DNS lookups

Regards,
-- martin

Dipl.-Phys. Martin Konold

e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Nobelstrasse 15, 70569 Stuttgart, Germany
fon: 0711 67400963, fax: 0711 67400959
email: martin.konold@erfrakon.de


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: Idea for more timely virusdb updates [ In reply to ]
Am Wednesday 11 August 2004 18:56 schrieb Mitch (WebCob):

Hi Mitch,

> > service. After all port numbers are a limited resource with todays IPv4
> > networks.
>
> bittorrent doesn't rely on a fixed port - it doesn't need one.

My above comment was an answer to the idea of letting an MTA run on an extra
fixed port. It was in no way related to bittorrent.

The problem with bittorent is that bittorent addresses a different problem
domain.

clamav pattern update:
- frequently changing small number of small files distributed from a single
point to many

bittorrent:
- slowly changing high number of potentially very big files distributed from
many sources to many destinations.

Regards,
-- martin

Dipl.-Phys. Martin Konold

e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Nobelstrasse 15, 70569 Stuttgart, Germany
fon: 0711 67400963, fax: 0711 67400959
email: martin.konold@erfrakon.de


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: Idea for more timely virusdb updates [ In reply to ]
OK folks, chiming in again with my more or less educated opinion.

DNS was built exactly to distribute fast and reliably small chunks of
information (most or the time address related information to start with).
Is an MX record now exactly an address related information, one would guess
yes. Was DNS based blacklisting thought about when the BIND system was
developed? I doubt it, still I believe most of you admins around use it in
some form. The DNS system will survive much heavier load then we could
possibly ever burden it with.

I believe a pull method is preferred over a push method, because it is
easier to manage regionally. A system administrator could even decide to
use a specific group of servers. I doubt that any sensible sysadmin will
allow a push to be implemented anyway .... seee security risk.

To build smaller update chunks I beg you to reconsider the patch method,
even though the files are binary. They could easily be converted to a
textual multi line representation, then diffed with enough redundant
information to assert the patch is inserted at the right place, possibly
compressed for transport and applied to a text converted file, which of
course would need to be converted back, checksummed, compared, you name it.
All the necessary tools to do this are standard on *nix systems and there
is always cygwin for the Redmond addicts.

cheers
Erich

THINK
P√ľntenstrasse 39
8143 Stallikon
mailto:erich.titl@think.ch
PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16




-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: Idea for more timely virusdb updates [ In reply to ]
On Aug 11, 2004, at 10:40 AM, Damian Menscher wrote:

> On Wed, 11 Aug 2004, Lionel Bouton wrote:
>
>> Since some time I am thinking of a bittorrent approach too. Bittorrent
>> is quite efficient at distributing files and there are implementations
>> allowing multiple trackers to distribute the remaining server-side
>> load.
>
> Please take this as a question rather than a criticism of the approach:
>
> My experience with bittorrent has been with downloading huge things,
> like Fedora. <snip>

I've never used bittorrent so I'm afraid I can't comment there.

> With regard to all the other ideas: Please remember to keep this
> *simple*. Here's where I, IMHO, think we stand:
>
> Opening a new port on a mailserver so updates can be pushed to it is a
> BAD idea. As a sysadmin, I would not allow such a thing on my
> production machines. It creates a huge security risk, since now you
> have one more opening to a remote root vulnerability.

Just a clarification of what I accidentally proposed earlier: it
wouldn't be so much a mail server doing this, just a daemon and
application modeled after mail. I think it's pretty clear thanks to
SPAMmers all around the Internet that email protocols are broken, but
the basic simplicity of the model behind SMTP could be applied to send
out a subscription of encrypted and signed updates to people who sign
up for it...it would be more like a whitelisted email system in
*concept* only. I was proposing that only because the basics are
already out there in framework in the form of email...but we don't want
something that accepts random or additional info. Just updates for our
Clam programs.

Yes, it could be another root vulnerability, and it would be a bigger
target because AV kiddies are usually the kind that are more likely to
attempt DOS attacks against servers if there's a central target to hit.

> I'm really starting to like the idea of a mailing list that can have
> dedicated (and random for each site) subscription addresses and pipe
> the
> list straight into "sigtool --add". It means we'd have to find someone
> to host the list, but that's probably no more difficult than finding
> someone to host a mirror. Presumably there could even be multiple
> "mirrors" sending the list, to improve speed (taking an idea from
> spammers who use open relays to do the hard part).
>
> One thing to add to the mailing list approach: there needs to be some
> sort of "heartbeat" or "dead man's switch" -- a way to know that the
> mailing list is functional, but there are no needed updates, rather
> than
> that the mailing list has broken. I suppose this might be a use for
> that latest-db-version.clamav.net idea.

Here's a second idea to combine with the first...use a freenet model.
At least I think that's the name...

It's P2P and anonymous; and (my memory is foggy...can someone confirm
the details?) it is kind of like a mesh "network within a network". It
was originally meant as a totally free and distributed way for P2P
transfers of information. Everyone shares information and it gets
distributed on computers, and you as a client/server have no control or
idea what is in your allocated "sharing space". Could be illegal
material, could be shakespeare, you don't know (Freenet, that is).

If we had a meshed system of a "live network within a network" of
updates with this model, it may be an interesting infrastructure not
only for rapid updates, but impossible (improbable?) denial of service
attacks, and the possibility of even tagging exe's for analysis
later...they could just be swept up in the "grid" and analyzed when
they reach the appropriate team members. The sigs could be updates and
swept into the grid where they'd be distributed to sysadmins.

Again, probably impractical, but just enjoying the brainstorming that's
going on on the list recently. :-) It would be more complicated that
previous ideas, yes, but it may lay groundwork for future features or
ideas, like maybe a way to monitor virus activity and send out
statistics to users who wish to setup that ability for monitoring
outbreaks in certain regions of the Internet.

-Bart



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: Idea for more timely virusdb updates [ In reply to ]
On Aug 11, 2004, at 1:22 PM, Martin Konold wrote:

> Am Wednesday 11 August 2004 16:19 schrieb Bart Silverstrim:
>
> Hi Bart,
>
>>> DNS was developed exactly for this kind of purpose.
>>
>> Storing non-DNS related information for retrieval? As I understand
>> the
>> proposition (and the original lecture that this idea was based on),
>> it's was for hiding information in a very small records area of DNS
>> for
>> propogating information...I don't think the designers for DNS had
>> spreading AV signatures (or files or other things that have been
>> proposed, non-Clam related) in mind at the time.
>
> Please be aware of the fact that I don't think that DNS is the correct
> tool to
> distribute files but for distributing something like a serial number
> it fits
> perfectly.
>
> The actual download of the data has to be done outside of the DNS
> system.

Okay, this would be where my misunderstanding was entering the picture
:-) I was thinking DNS would be the distribution engine, not the
notification engine.

Sorry for the confusion!

> Abusing the DNS to directly transfer files etc is not appropriate as
> the DNS
> infrastructure is not ready for such kind of "abuse".

Give it time...someone's going to do it.

I'm surprised someone hasn't found a hole in DNS that would allow it to
act as a way to distribute viruses via DNS records yet...

-Bart



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Clamav-users mailing list
Clamav-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clamav-users

1 2 3  View All