On 29/05/16 10:22, Groach wrote:
On 29/05/2016 10:19, kristen R wrote:
It should be obvious although not mentioned that everyone who uses
clamav is your fan club. I am a fan.
I also believe that clamav is an open source project? So if someone
doesn't like this product then they might submit a patch for improve
features or functionality?
If this is true, then bitching is unproductive. Else put your code
where your mouth is.
Kristen
I agree. So, all you people that dont like the product and it features
of ClamAV, come on and put your hands up, stop bitching and submit your
own patches. (Although the slight flaw in the statement is the
assumption that all users have the ability to code and fix the product.
If everyone that drives a car had the ability to fix them too, there
wouldnt be any service garages would there. And not being skilled enough
to fix the car themselves doesnt mean they have to accept the
ineffective brakes 'as a feature'. In reality, of course, most people
are simply too busy running an IT department or mail server to learn
such new skills and leaves coding to CODERS.)
And, army of disgruntled coders, whilst youre at it, maybe you can also
help to solve the REAL PROBLEM of the signatures out too (effectivity
and frequency). Then the rest of us that like Clam (for its opportunity
to employ more useful 3rd party signature) can also benefit. After all,
of Sane security can make effective signatures, as a one man unfunded
operation, then why oh why cant a CISCO-backed 'company' with its code
open to the worlds programmers not do the same? (Irony, anyone?)
I don't normally respond to this type of thread but felt compelled to
add my 2p worth of experience.
I love open source software and have run ClamAV on my own mail server
for as long as I care to remember. I was also an active member of the
anti-malware research community for a considerable time.
IMHO anti-virus products lost the battle a long time ago - it is simply
not realistic to expect ANY company, commercial or open source, to be
able to produce signatures for the number of new virus samples that
emerge in a timely fashion. It has been this way for a long time. The
numbers bear this out. A new paradigm is needed. I once hoped heuristic
detection might have been the way forward but this doesn't seem to have
produced the required results either.
This led me to conclude that all anti-virus products are essentially
ineffective. Submitting samples I collect that hit my mail server spam
traps to Virus Total support this conclusion (YMMV). Detection rates are
abysmal at the time I collect the samples.
For me, as for others who have posted in this thread, the solution is
simple - I simply do not permit executable code to pass through my mail
servers. I can not think of a case where allowing executable code to be
distributed by email outweighs the risks. Where is does, and the user
can make a genuine risk-assessed case, it is easy enough to add case by
case exceptions for individual users. Problem solved, at least from the
mail server prospective.
Admittedly I am operating at the lower end of the market where it is
easy for me to impose such unilateral policies, but I would make the
same case all the way up to large corporates and ISPs. No reason an ISP
can't operate the same default policy and provide a mechanism to allow
users to opt out if they find the need to send executable code by email
(some large ISPs block outbound tcp25 connections to address spam issues
so they can do it when they want to). And given the numerous recent
examples of large corporations suffering costly data leaks, even they
should now be willing to take security concerns more seriously rather
than scoffing at IT departments always trying to impose more restrictive
(paranoid) working practices.
Where ClamAV should (or could) have an advantage over it's closed source
relatives is in the sheer number of volunteers the project has the
potential to mobilise. The ClamAV Project has the potential to mobilise
a huge army of open source volunteers, all writing and sharing community
signatures for the samples they collect. The framework to do this
already exists. Would this be enough to represent timely and efficient
detection of threats, who knows, but it is a potential resource that is
simply not available to commercial AV companies. The samples are there,
everyone is willing to share them, but no one company has the resources
to protect their users from all of them due to the sheer volume. So the
industry needs to develop a new way of working or it will die - either
it collaborates (a concept already embraced by the Open Source
community) or it comes up with a new way to protect it's users (e.g,
heuristics), or people will stop paying an annual fee for a product that
fails to protect them (I would rather spend that money of user education
than an ineffective AV product).
In reality the AV industry died for me some while ago with the
realisation I am simply unable to rely on the product to produce
anything resembling acceptable levels of performance. Harsh maybe, but
IMHO it's simply not fit for purpose. As I mentioned above, as a
postmaster I solved the problem by simply not allowing executable
attachments. I do still run ClamAV on my mail servers, it uses few CPU
cycles, detects nothing but I figure it does no harm so why mess with a
system that isn't broken and has worked for years.
_______________________________________________
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
