Re: [clamav-users] clam av Red Hat installation
On 24/12/13 07:22, Joshua Soulwin Malayappan wrote: Hi Dennis, When I tried to install I got the message It is not a valid rpm. Can you suggest perhaps a link to zlib/zlib-dlevel rpms. Thanks, Josh Josh, You should use yum, the package manager within RHEL, as this will automatically resolve package dependencies for you. zlib/zlib-devel packages are part of the distro and will be automatically installed as required when you install clamav. For example, after setting up the repoforge repository which contains the clamav packages, all you need is: yum --enablerepo=repoforge install clamav and yum will take care of all the dependencies for you. ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/support/ml
Re: [clamav-users] ClamAV+exim: scanner finds not a single malware
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
Re: [clamav-users] Daily 23161 broke Clam
On 03/03/17 23:53, Scott Kitterman wrote: As far as I can tell, pcre 7 came out before 2008. I think a decade is enough time to insist people upgrade. Scott K Red Hat typically now supports each release of RHEL for at least a decade, and that's not including any additional extended support periods one may purchase from Red Hat in addition to the standard production lifespan, so in a Red Hat world, I would say a decade is the *minimum* period one should support dependent libs if you want your software used on that platform. RHEL5 may reach end of production on 31 March 2017 but extended life-cycle support continues until 30 Nov 2020, so preferably support for pcre-6 should continue until then. https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates A huge number of mail admins want to install a RH mail server and forget about it for 10+ years knowing it is supported and will just work, and that things aren't going to continually break with each and every update. I'm currently in the process of installing a new mail server to replace a RHEL5 server, initially set up in 2007, and only because RHEL5 is EOL. The same hardware (touch wood) is still going strong and hasn't missed a beat in 10 years. If I could afford the extended support from RH I'd probably let it run for another 3 years. So your opinion on this will be influenced by your perspective. I would argue that RHEL has a large enough installed userbase to warrant supporting it for at least it's 10 year production life-cycle. On Friday, March 03, 2017 11:21:30 PM Joel Esler wrote: If we required pcre 7, it would allow us to publish this kind of sig in the future of 99.3 and high versions by requiring a certain "flevel". -- Sent from my iPhone On Mar 3, 2017, at 18:18, Chris Conn wrote: Hello, Looks like my off-list email went on the list LOL. So much for not making noise. Woops. If the 0.99.3 or whatever later version where this would be implemented requires PCRE 7, would that break database updates for versions that have not upgraded if this pcre format is re-used in the future, or would it simply disable pcre support in previous version of clamd that have not been upgraded? Thanks, Chris On 3/3/2017 6:13 PM, Joel Esler (jesler) wrote: A new daily with the Sig dropped. Probably what we will do to prevent this from happening again, is to have 0.99.3 (the upcoming version) require pcre 7. How does that sound? -- Sent from my iPhone On Mar 3, 2017, at 18:08, Chris Conn wrote: Hello, I hope you don't mind my contact off-list, I don't want to make noise on it for all. Apologies. This new build, are we talking about a daily.cvd (23162?) or a new build of clam/pcre? Thanks again in advance for your help, Chris On 3/3/2017 4:00 PM, Alain Zidouemba wrote: We are coming to the same conclusions. The issue seem to isolated to using pcre libraries older than 7.0. I does not affect users of newer versions of pcre or users of pcre2. A new build with the fix is in progress now. Apologies for the impact this has caused. Alain On Fri, Mar 3, 2017 at 2:34 PM, Steve Basford < steveb_cla...@sanesecurity.com> wrote: On Fri, March 3, 2017 7:20 pm, Alain Zidouemba wrote: We're pulling the signature causing the issue now, while we investigate the cause. - Alain Hi Alain, I think the fix is... Replace ? with ?P when the PCRE library is old ie. ?< to ?P< On... Doc.Macro.GenericHeuristic-5901772-0 Doc.Macro.GenericHeuristic-5931846-1 -- 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
Re: [clamav-users] Daily 23161 broke Clam
On 04/03/17 22:54, Joel Esler (jesler) wrote: We cannot be tied to distribution support problems. That's fine Joel. You obviously know your own target audience. If it's not me I can look elsewhere for solutions :-) On Mar 4, 2017, at 17:44, Benny Pedersen wrote: Leonardo Rodrigues skrev den 2017-03-04 23:12: is clamav a redhat product ?!?! I don't think so. That being said, i see absolutely no point at all on saying clamav should do this because redhat does that. good point Anyone wishing to be updated with a 10+ years rhel install, should call redhat for that :) any rpm builded systems are buggy my 0.02 cents ... anymore left ? i just wish 0.99.3 have clamav-milter supporting OnUnOfficiaLsignature accept|quarantine|reject that will save me to have need for 2 clamd and 2 clamav-milters just my one bitcoin :) clamav-owner please stop breaking dkim ___ 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 ___ 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
