Re: [Clamav-users] Script updated: clamav-unofficial-sigs.sh (v3.7)
MSRBL (as it's no longer being updated) And here's the answer from the actual project: http://msrbl.blogspot.com/2010/01/msrbl-status-update-as-some-of-you-have.html It's amazing what information you get when you actually talk to people. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Script updated: clamav-unofficial-sigs.sh (v3.7)
removes MSRBL (as it's no longer being updated) Did they declare themselves to be defunct, or are you declaring it for them (without any actual announcement from them)? Do you have any indication that MSRBL is still alive and that the signature databases are being actively updated? What do you mean by active? within the last 6 months? Yes. And I don't recall them having been a high volume of updates data source before that. Or are you just trolling? No, just trying to determine the credibility of the statement, considering you've made unqualified announcements, about other people's projects, in the past. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Script updated: clamav-unofficial-sigs.sh (v3.7)
Then you don't have a clue and are obviously not qualified to make a judgment call on this matter. They used to routinely have some signatures that would go weeks, even months, without updates. I used tolook at their signatures and see that they were a month or two old ... and a few months later, it was still only a month or two old (so, clearly, they updated in the mean time). Most recent update from them was 3 months ago. Two others were 6 months ago. Definitely pushing the envelope of their past pattern, but it's more recent than a year ago, by a factor of 2x or 4x (depending on which signatures you look at). Only your orphaned botnet project. Still not orphaned, still not in need of a new version, and you're still not qualified to make that declaration. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Script updated: clamav-unofficial-sigs.sh (v3.7)
Most recent update from them was 3 months ago. rsync rsync://rsync.mirror.msrbl.com/msrbl/MSRBL-SPAM.ndb -rw-r--r-- 244643 2009/07/27 01:21:23 MSRBL-SPAM.ndb rsync rsync://rsync.mirror.msrbl.com/msrbl/MSRBL-Images.hdb -rw-r--r-- 181337 2009/07/24 03:40:17 MSRBL-Images.hdb rsync rsync://rsync.mirror.msrbl.com/msrbl/MSRBL-Images-FULL-SoN.hdb -rw-r--r--19030813 2009/10/07 15:50:05 MSRBL-Images-FULL-SoN.hdb 3 months ago. Only your orphaned botnet project. Still not orphaned, still not in need of a new version, and you're still not qualified to make that declaration. Strange that others must provide patches for your project them, since you haven't provided an update in nearly 3 years. Only a very few sites seem to need it, making it, as far as I've observed, an edge condition. Not a general need. There hasn't been any OTHER reason to make changes to it. If there was something critical and wide-spread, sure. If there was a new feature to incorporate, sure. Neither of those are true. And, as I've said before, and you're well aware, the direction that the given patch goes isn't the direction I want to go with botnet. The change doesn't need to be in the general dist. The change doesn't fit the direction I want to go with the package. There aren't any other reasons to update it. So there hasn't been a need to update it in 3 years. That doesn't make it orphaned. It makes it not in need of new releases. If one of those needs comes up, if the plugin API changes, or if I see the need for a new feature, it will get addressed. All of which gets back to: you have no business making announcements about projects for which you aren't a spokesperson. So, when you do make those announcements, it's perfectly reasonable for someone to ask you back up your statement ... because your statements lack credibility. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Script updated: clamav-unofficial-sigs.sh (v3.7)
rsync rsync://rsync.mirror.msrbl.com/msrbl/MSRBL-Images-FULL-SoN.hdb -rw-r--r-- 19030813 2009/10/07 15:50:05 MSRBL-Images-FULL-SoN.hdb Only the clueless would use that database. Which is irrelevant to the point. The point isn't is it a reasonable/accurate/etc. database, the point is it is/was still active within the last few months, exactly within the behavior I described. Which goes back to the main point: your claims about other people's projects aren't credible. Final thoughts: It's my script, if I want to remove a database (with or without justification), my prerogative. No one said otherwise. I didn't say you can't remove them. I asked about the source of your claim that they're no longer providing updates, when they're still within the larger scope of their past behaviors. Given that you make unqualified claims about other people's projects, I was asking for the source of your claim, so that I could judge if it was real (and react accordingly in my own clamav signature update script), or another assertion without credibility on your part. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Script updated: clamav-unofficial-sigs.sh (v3.7)
removes MSRBL (as it's no longer being updated) Did they declare themselves to be defunct, or are you declaring it for them (without any actual announcement from them)? ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
[Clamav-users] APER
Hope I haven't missed this one being discussed... but ... APER is a project hosted at Google Code (Anti-Phishing Email Reply) that tracks From, Reply-to, and Body URLs that match known phishing attacks. There are a few examples for how to use it ... but I was wondering: Has anyone turned this into a regularly updated set of ClamAV signatures? I've been tasked with implementing it, and I'd love to be able to just plug it into my existing regiment of ClamAV signatures (I currently use MBL, MSRBL, and some (but not all) of the signatures hosted at Sane Security). ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] APER
Check out Julian Field's ScamNailer: http://www.scamnailer.info/ 18/10/2009 - New scamnailer.ndb ClamAV signature database is now available from http://www.mailscanner.eu/scamnailer.ndb. This is updated very frequently. Do not download it more than once per hour! Cheers, Phil While I have a lot of respect for Julian's work (I used to use mailscanner), and it's great to see more anti-phishing resources ... I don't see anything in the descriptions that says it's based on APER. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] APER
I have to ask however. You mentioned it contains phish urls as well. I have not been able to find that. However, we track phish urls/domains in winnow_phish_complete.ndb Tom When you download their distribution, you get 4 files: phishing_cleared_addresses phishing_from_addresses phishing_links phishing_reply_addresses The file phishing_links is what I was referring to. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] APER
Firstly, spear.ndb generated from the APER feed and has been for a while now: http://sanesecurity.co.uk/databases.htm I didn't realize spear.ndb includes APER. That's great news (as we already use spear.ndb) ... looks like implementing APER is pretty straight forward (and low effort) for me :-) is spear using all 3 parts (from, reply, and links)? Just want to be sure, when our director asks. Secondly, I've two more databases coming online soon based on their feeds... watch this space, as they say ;) Great! I look forward to hearing more :-) Cheers, Steve Sanesecurity Thanks! ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
[Clamav-users] Microsoft Power Point and Zip Files
(sorry if this has come up and I missed it) Apparently, the later/latest versions of Power Point actually write out zip files that are merely named .ppt (or something like that). Internally, it's apparently representing the slides and images as sub-files within the zip archive. This means that large Power Point presentations might have HUGE numbers of files in them, that might exceed the ClamAV archive file format. In fact, we've had some reports that look just like that. a) are other people seeing this problem? (was it fixed in a clamav version during the last 12-18 months?) b) has anyone solved it by just increasing the archive file limit? If so, what reasonable number have you come up with? Other thoughts of conclusions about all of this? (other than don't use MS Office -- that's outside the scope of my powers) John ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] test for SafeBrowsing?
On Wed, Mar 18, 2009 at 05:55, Dennis Peterson denni...@inetnw.com wrote: Moray Henderson (ICT) wrote: From: Török Edwin [mailto:edwinto...@gmail.com] Try using a href=... for the URL. Is that a requirement? If so we should get the spammers on board because some of them may not know this :). No, there are more places from where URLs can be extracted, but a href is one that must work. With modern email clients helpfully presenting text that looks like a URL as a real URL at the client end, SafeBrowsing really ought to check the plain text, not just within html tags. http://pastebin.com/m13232c54 may be just plain text when transmitted and scanned, but it's an a href by the time I read it: underlined, blue, and turns my cursor to a pointy finger with a pop-up box saying Click to follow link. I don't imagine the world's premier spammers are sitting at their laptop in their shorts sending out thousands of spams with Thunderbird. There are purpose built products for this and can format the mail any way they wish. Whether or not they're sending using Thunderbird isn't relevant. What's relevant is whether or not they know that the receiving mail clients will try to turn plain text URL's into clickable links. I'm pretty sure that, no matter what sending tool they're using, they're aware of this feature of modern mail clients. And I'm also very sure, from having seen it in the wild, that they exploit it. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] TROLL NEST (was Non-Windows Malware)
I think that was the point Dennis and I were making, with varying degrees of subtlety and manners. :-) On Wed, Dec 10, 2008 at 11:10, Jim Preston [EMAIL PROTECTED] wrote: Derek sed with a straight face: # Of course not. The arrogance of certain # dysfunctional clowns on this # list is outrageous. I never run into this # rubbish except at troll # dens, which apparently this is. It's a very recent problem - it started just a few days ago. Unfortunately you got here right at the beginning. Hopefully things will return to normal soon. Dp Actually, I think it was derek who started it.. Best, Jim ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Non-Windows Malware
On Mon, Dec 8, 2008 at 19:25, Derek Currie [EMAIL PROTECTED] wrote: This list is incredible. Rudeness deluxe. Forgettable. I don't suppose you've considered that you're the common element in all of that. Probably not. Easier to blame the list (that had extremely few problems with rudeness before you got here), or other list members ... rather than looking inward at your own part of the exchange. You reap the crop you sow. When you reap something a lot, you should ask yourself what you've been sowing. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Announcing ClamAV 0.94.1 RC1
Tomasz Kojm wrote: On Thu, 16 Oct 2008 17:41:50 -0700 John Rudd [EMAIL PROTECTED] wrote: Do you have any thoughts about how we can get the stats to you, so that you can use them, without bypassing our mechanism for ensuring consistent and safe updating of our virus signatures? You could just run freshclam --submit-stats=/path/to/clamd.conf on the hosts that get real traffic. Would that work for you? It would if I was using clamd... which I don't. I use the clamav libraries via perl. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Announcing ClamAV 0.94.1 RC1
Tomasz Kojm wrote: Freshclam also submits information about detections with 3rd party signatures. We only have one host in our environment that does freshclam (or any of the other virus signature update mechanisms). It verifies the validity of the data (makes sure nothing will die as a result, etc.), and then pushes the new data out into a shared data space for the other hosts to pick up. This is done both for our own internal safety/sanity check AND to ensure all of our production hosts get the same data at the same time. It also means that no matter how many production hosts we have, we only impact each signature site with one database refresh per update cycle. The host in question doesn't get much (if any) traffic, except when we're running tests. So, even then, it only gets synthetic traffic, not real traffic. Meanwhile, the hosts that get real traffic don't run freshclam at all. Nor do we want those hosts to ever run freshclam (at least, we don't want them to ever run freshclam for the purpose of receiving new virus signatures). Do you have any thoughts about how we can get the stats to you, so that you can use them, without bypassing our mechanism for ensuring consistent and safe updating of our virus signatures? ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] [0.0] Re: Stop it!
Jerry wrote: It is not the operating systems job to stop the user from shooting himself in the foot, but rather to deliver the bullet as efficiently and expeditiously as possible. If that were true, we wouldn't have things like protected memory, chroot jails, etc. in our operating systems, as those all interfere with all sorts of bullets. What you're describing is the caveman approach to providing systems and services. And, over time, the discipline has evolved to understand that that's actually a rather counter-productive mindset. Every level of the computing infrastructure provides safe guards to prevent people from doing exactly what you've said: shooting themselves in the foot. The idea that the OS shouldn't be participating in that is outdated, and ignorant. The idea that each application developer doesn't also have a role to play in those protections is of a similarly out-of-date and out-of-touch mindset. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Stop it!
Bowie Bailey wrote: However, doesn't this already exist with the upgrade notes? Take a look here: https://wiki.clamav.net/Main/UpgradeNotes093 I don't know if they are this detailed on all of the releases (the notes for 0.94 don't say much), but this looks like exactly what John was asking for. That one is a GREAT example of what I'd like to see for every release that affects the config file. And, you'll notice that the other Upgrade Notes pages make no mention of such changes. If that's all there was, those Upgrade Notes pages, and they were consistently annotated with these sort of changes (in every release), and the location was well advertised, I'd be happy with it. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Stop it!
Dennis Peterson wrote: With the tools we have available to us today there is no reason a failed process should remain a secret. Which does not explain the push-back on having the applications/services/daemons provide better documentation and triggers for helping that effort, instead of immediately attacking the OP as though they're an inadequate sysadmin for having requested that higher level of participation from the application/service/daemon authors. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Stop it!
At the very least, when the config file and options change, the ClamAV team should post a notice which explicitly lists (and only lists): 1) new config items 2) removed config items 3) config items whose syntax, semantics, or options changed, and how 4) supported but deprecated items, and what, if anything, replaced them This shouldn't just be buried in release notes, a read me file, or a change log. It should be in those places _TOO_, but it should also exist as its own stand-alone statement that any one of us can easily see and find. And what they REALLY ought to do is supply a tool which reads old config files, and does something like a lint check. With multiple verbosity level options, it should read the existing config file, and say things like which lines have errors, what's wrong with this line, what parts of that line are no longer supported, and if possible give the new/current syntax for the line in question. In the most trivial case, you should be able to invoke: clamavcfgcompiler -o oldconfigfile -n newconfigfile and it will generate the new config if there are no errors, generate STDERR reports for deprecated options that aren't show-stoppers, and generate STDERR reports and not generate a new config file if there are show-stopping errors. For those who say as a sysadmin you should follow best practice X to prevent these problems... the same is easily leveled at the clamav developers. They have best practices they should follow as well, with regard to supplying software that is commonly, widely known to be, and intended to be, used in such critical roles. And, really, they no loner get to hide behind it being a community project, it's now owned by a company. If they want to maintain the integrity of a company image that provides software that is reliable, especially reliable in mission critical roles, then they need to address this ASAP. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Stop it!
Jerry wrote: The sad part is that they will continue to blame others for their lackadaisical approach. So, let me attempt to summarize your side of this here (and do correct me if my summary is wrong, as I'm not trying to build a strawman argument). You're justifying the laziness of the developers by accusing the users/sysadmins of being lazy? Seems a little hypocritical, doesn't it? I'll put forward two counter-arguments to this: 1) No one is advocating laziness on the part of the user/sysadmin, we're requesting at least better information, and better organized information, from the developers so as to better support the users/sysadmins. And, ideally, better tools to help their consumers as they change the infrastructure they provide. Not so that their consumers can be lazy, but because every bit of due diligence on _everyone's_ part is good for the whole ecosystem. 2) The proper mantra of computing, due to the constant trend of providing computing resources becoming cheaper over time (and thus always becoming more cheap than the price of time of the consumer) is: it is the burden of the provider to leverage their resources so as to lessen the workload of their consumers. I can go on and on about how this relates to the cost of a developer hour vs the cost of 100's of user hours, or the cost of a task in CPU dollars vs the cost of that task in human dollars, and how these always change in favor of the humans being more expensive than the computers/developers/sysadmins. Or how this all feeds into each layer making their downstream consumers more productive and effective by automating the tasks, or bolstering the infrastructure, of their downstream consumers, freeing them up to take on bigger and more important/productive tasks. But what it boils down to is: - it is the burden of sysadmins to take on more work so as to lessen the workload of their users. (hopefully taking on this work by providing better streamlined services, and more effective and comprehensive infrastructure for their users to leverage) - it is the burden of developers* to take on more work/tasks so as to lessen the workload of the sysadmins, users, and other (down stream) developers who are consuming what they're developing. (* whether they are developing hardware, OSes, or applications) (the burden of the user, incidentally, is to not rest more as their tasks become more automated, but to use the freeing up of their effort as a resource to apply in being more productive and effective, making society as a whole more productive and effective; thus, the role of computing in general is to support the advancement and productivity of society as a whole) (and, while that may sound like a workers paradise, recreation/entertainment is an appropriate form of productivity in this sense, where that type of productivity is part of improving the enjoyment of our lives, so this applies equally well to computer games, computer supporting movie makers and other artists, etc., or making both our society and or lives better by making us much more productive during the work day, lessening the time spent working on our private lives, and thus letting us get out of do more basic forms of enjoyment with the rest of our time) Anyone in the computing ecosystem who isn't embracing this is dead weight in the ecosystem, and thus dead weight to society, and should be treated as such. The point of that lecture: lazy developers, who are doing things that get in the way of their customers being more productive by making it harder, instead of easier, to find information about important or critical changes in their software, are not playing their proper role in computing. Thus, they are leaning toward being dead weight, and should be treated as such. The fact that this is being pointed out to those developers doesn't mean that the sysadmins/users are trying to be lazy. For those ignorant among you who are taking this point of view, the purpose of the request, instead, serves making those sysadmins have more time to empower their users, and making those users have more time to improve society. Suggesting that it is just sysadmin laziness is at best specious and ignorant, and at worst being willfully obtuse. Either way, it's counter-productive to the software ecosystem as a whole. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Stop it!
Jerry wrote: On Sat, 04 Oct 2008 14:04:22 -0700 John Rudd [EMAIL PROTECTED] wrote: Jerry wrote: The sad part is that they will continue to blame others for their lackadaisical approach. So, let me attempt to summarize your side of this here (and do correct me if my summary is wrong, as I'm not trying to build a strawman argument). You're justifying the laziness of the developers by accusing the users/sysadmins of being lazy? Seems a little hypocritical, doesn't it? So now you are accusing the developers of being a group of lazy bastards. I am sure that, that will encourage them to hasten a fix (which assumes something is broken, and I am not of that frame of mind) for your problem(s). I never said bastards. Thanks for conflating things, and continuing to show you're just taking the point of hypocrisy and willfully being obtuse. Did you take lessons in de-railing discussions from Karl Rove? I'm going to guess that next you're going to accuse me of having an interracial lovechild out of wedlock... And, no, I'm not accusing the actual ClamAV developers as being lazy, I'm characterizing/summarizing the resistance argument (to the original request(s)) by the naysayers. Nice attempt at a strawman, though. On a serious note, if you are so unhappy, and your tone definitely indicates that you are, the solution is easily within your grasp. I'm not unhappy with ClamAV. I'm unhappy with the naysayer arguments being given (by you and Dennis in particular). They're childish, misleading, and counter productive to the overall software ecosystem (and ClamAV in particular). ClamAV, in general, is a gem with rough edges. A few of us are suggesting a means of refining a few of those rough edges. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Eric Rostetter wrote: Quoting John Rudd [EMAIL PROTECTED]: Tilman Schmidt wrote: So why am I dissecting that list like this? Just to show that blocking or not blocking certain unusal characters in mail addresses is indeed a policy decision which should not be forced by a piece of software, but at most offered as a configurable option. Absolutely agree. I disagree in this case (read on). It is not ClamAV's place to make policy decisions for me. And ClamAV does not. The milter is. And the milter is designed to work with sendmail. And if leaving this enabled by default produces an exploitable sendmail, then it is wrong. It does not. What leaves an exploitable sendmail is a poorly configured sendmail. The problem is already fixed, and properly fixed, in sendmail's own configs. This makes it the wrong tool for the job. Adding this to the milter is adding code to fix something that isn't broken. It is never good to be the wrong tool for the job, nor fixing something that isn't broken. And, therefore, it is doubly bad to be both. Further, it imposes this fix upon mailers that don't have a vulnerability (keeping in mind that other MTAs can use milters now). That's three strikes*. (* yes, I know most of the readers here might not be in the US, nor familiar with baseball metaphors, but hopefully they'll get that three strikes is a threshold of disqualification) I'm not saying it can't be configurable, but whether it is or not, it must be disabled by default, IIF it is known to make sendmail or the milter itself exploitable. That would be true if and only if the proper fix didn't already exist within sendmail itself. (and I don't recall if it's the default in sendmail, or not ... but that doesn't matter, because the PROPER FIX is to use the sendmail config which stops the exploit ... that proper fix might be as simple as do nothing, if it IS the default) At most, it should offer me policy options, but only _options_. You would rather it allows you to become exploitable? I wouldn't... Nice strawman. No, I wouldn't like to be exploitable. And, without this feature, I wouldn't be (not even if I was running sendmail), because the fix already exists within its proper location (within sendmail itself). IMHO, the proper thing to do is to document this in the milter docs. Whether it becomes a configurable option or not, it should certainly be documented that the default is to block such addresses. No, the proper thing to do is not fix things that aren't broken. This is already fixed in the proper place. At the most, the ClamAV team, and/or the clamav-milter team, should provide a STRONG recommendation that the sendmail config should use its existing technique for fixing the problem (which may be as simple as do nothing except don't overide the default). BUT, the point of my email is ClamAV is an anti-virus program, its jobs is to match patterns and report the match. clamav-milter is a separate program, a milter for sendmail. A milter is by definition a filter. It's job IS to filter (see: https://www.sendmail.org/milter/), even though many people use them in a non-filtering way... Don't confuse the two programs, or their functions. Close, but not correct. Milters in general exist to provide general filtering capability. The clamav-milter is not a general milter. It's a specific milter, whose specific purpose is to provide ClamAV capability via the milter interface. Your argument here would be valid if the clamav-milter were a general purpose milter, such as MIME-Defang. Or if it were a special purpose milter whose special purpose wasn't specifically providing ClamAV via the milter interface. Again, it is providing a fix in the wrong location, and fixing something that isn't broken. It would be irresponsible for a milter to knowingly allow a security hole by default. Incorrect. It is irresponsible for a milter to allow a security hole IN THE AREA THAT THE MILTER ADDRESSES. The clamav-milter isn't a general security tool, it is a _ClamAV_ milter. By your logic, EVERY milter on the planet should waste its time doing EVERY security check known in order to be sure that not only is sendmail not mis-configured, but neither is every other milter in use. That's wasteful, poorly conceived, and just a plain bad idea. Use the right tool for the job. Fix the problem where the problem exists. The right tool for the job is the existing sendmail fix for the problem. The proper location of the fix is within the sendmail configuration. Not in EVERY milter on the system. Not in ANY milter on the system. Protecting against such a hole is the only reasonable thing to do. How to best protect that hole is still a subject of debate. No, it is not. The best protection for that hole already exists within sendmail. Fixing it within the clamav-milter is _STUPID_. ___ Help us
Re: [Clamav-users] US-CERT alert regarding ClamAV
James Brown wrote: On 16/04/2008, at 4:33 AM, fchan wrote: This part of clamav-0.92 and new fix of a bug. https://wwws.clamav.net/bugzilla/show_bug.cgi?id=613 And in short we need to get gcc4.1.1 or newer to get this work on Macintosh 10.4.11 and xcode 2.5 which only has an gcc 4.0.1. However Apple hasn't released gcc 4.1.1 or newer for the Mac 10.4.11 so we are left to use this an workaround for this an Japanese clamav user found this and here is the workaround: export CFLAGS='-g' -g means debug mode building. Then configure and make as you have done before. I hope this helps. Frank John Rudd wrote: Oh, and, while we're on the subject, what about 0.88.6? is that version vulnerable? (don't tell me to upgrade -- I haven't been able to get newer versions to compile on Mac OS X 10.4.x) Frank John, I've used ./configure --enable-experimental CFLAGS=-O0 to get ClamAV (including 0.93 yesterday) to compile on Intel Macs (as have others). I'll check to see if it works on a PPC mac (I don't have a Intel Mac). ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Dave Warren wrote: In message [EMAIL PROTECTED] Stephen Gran [EMAIL PROTECTED] wrote: On Mon, Apr 14, 2008 at 05:22:56PM +0200, Bas van Rooijen said: postfix would accept all three forms even and why not ?? I assume you haven't looked at sendmail's security record. I, for one, have made it a point to not care. This has been a pretty standard thing to do for a long time, and with even more characters than the milter currently uses. Can we get any email address banned in clamav just because at least one software package has an associated exploit? Especially when that exploit is easily, and MORE APPROPRIATELY, plugged in the software package itself, instead of acting as a potential bloating-agent in ClamAV? ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] US-CERT alert regarding ClamAV
Nigel Horne wrote: Roberto Ullfig wrote: Nigel Horne wrote: A vulnerability was identified by Secunia in 0.92.1 relating to the PE module. We immediately disabled this module about a month ago. Since then we have been working on, and produced, a fix which is included in 0.93. 0.93 is due for release very soon, and all users are advised to update to this release with immediate effect. 0.93RC1 does not include the fix. Regards, By disabling the module do you mean to say that 0.92.1 is not vulnerable? Why does CERT say otherwise? As soon as we found out about the vulnerability we issued a dconf update to switch off the affected module, upack. All 0.92.1 users are advised to upgrade to 0.93 immediately. So, are 0.92.1 users temporarily safe due to the [freshclam?] update which turned off the module? Or not? By throwing in the trailing statement, you're confusing things. Just answer the question about 0.92.1 being vulnerable, without repeating whether or not people need to upgrade. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] US-CERT alert regarding ClamAV
Nigel Horne wrote: Roberto Ullfig wrote: Nigel Horne wrote: A vulnerability was identified by Secunia in 0.92.1 relating to the PE module. We immediately disabled this module about a month ago. Since then we have been working on, and produced, a fix which is included in 0.93. 0.93 is due for release very soon, and all users are advised to update to this release with immediate effect. 0.93RC1 does not include the fix. Regards, By disabling the module do you mean to say that 0.92.1 is not vulnerable? Why does CERT say otherwise? As soon as we found out about the vulnerability we issued a dconf update to switch off the affected module, upack. All 0.92.1 users are advised to upgrade to 0.93 immediately. Oh, and, while we're on the subject, what about 0.88.6? is that version vulnerable? (don't tell me to upgrade -- I haven't been able to get newer versions to compile on Mac OS X 10.4.x) ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] US-CERT alert regarding ClamAV
John Rudd wrote: Nigel Horne wrote: Roberto Ullfig wrote: Nigel Horne wrote: A vulnerability was identified by Secunia in 0.92.1 relating to the PE module. We immediately disabled this module about a month ago. Since then we have been working on, and produced, a fix which is included in 0.93. 0.93 is due for release very soon, and all users are advised to update to this release with immediate effect. 0.93RC1 does not include the fix. Regards, By disabling the module do you mean to say that 0.92.1 is not vulnerable? Why does CERT say otherwise? As soon as we found out about the vulnerability we issued a dconf update to switch off the affected module, upack. All 0.92.1 users are advised to upgrade to 0.93 immediately. Oh, and, while we're on the subject, what about 0.88.6? is that version vulnerable? (don't tell me to upgrade -- I haven't been able to get newer versions to compile on Mac OS X 10.4.x) er.. Sorry, I'm using 0.91.2, not 0.88.6, on my Macs. (using 0.92.1 on my Solaris boxes) ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Tilman Schmidt wrote: So why am I dissecting that list like this? Just to show that blocking or not blocking certain unusal characters in mail addresses is indeed a policy decision which should not be forced by a piece of software, but at most offered as a configurable option. Absolutely agree. It is not ClamAV's place to make policy decisions for me. It is ClamAV's place to match email messages to signatures. It is up to me what to do with messages that match signatures. At most, it should offer me policy options, but only _options_. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
Török Edwin wrote: [EMAIL PROTECTED] wrote: Bas van Rooijen wrote: Thanks for the replies so far; however please note I already know the problem is ClamAV (hence i'm writing to this list..) Is there anyone who can answer my actual questions? Comment out the check in the source and recompile? That check was added to prevent an exploit when run in black-hole mode. Then maybe it should only be active when run in black-hole mode? (maybe it is, I don't know if that applies to the OP). At the very least, shouldn't it have a config switch? ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] WARNING: Suspicious recipient address blocked
David F. Skoll wrote: Stephen Gran wrote: I assume you haven't looked at sendmail's security record. This has been a pretty standard thing to do for a long time, and with even more characters than the milter currently uses. That may be true, but filtering suspicious recipient addresses is beyond the scope of a virus-scanner, IMO. Much like my complaints about the PhishingScanURLs setting, I believe ClamAV should stick to the basics and leave other policy decisions alone. Or at least leave them off by default, and make them things you can easily switch on and off. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Memory usage for clamd is huge
rick pim wrote: Dennis Peterson writes: But we know from the volumes of spam and viruses now approaching if not exeeding 90% that you are the exception, not the norm. spam yes, viruses. not so much. our experience has been that email-borne viruses are way, way down: yesterday's logs from one of our mail gateways said there were about 15 viruses caught in something more than half-a-million email messages. phishing is up, of course, but viruses (i'm one of those folks that mentally files phishing under 'spam') are way down. Same observation here. 90-95% of my traffic is some sort of crap (spam, phishing/fraud, viruses, attachments with dangerous filenames), yes. But a very very small percentage of that is detected viruses and attachments with dangerous filenames (we reject both during SMTP). The VAST majority of what we're rejecting with ClamAV these days is phishing/fraud stuff. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Memory usage for clamd is huge
Dennis Peterson wrote: And to follow up on the earlier point about Windows systems not being the sole source of spam/virus distribution, The idea that any platform (windows, unix/linux, etc.) attached to the net cannot be subverted into being a spam/virus zombie is, at best, naive. And a naive sysadmin is a danger to us all. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Memory usage for clamd is huge
Joe Sloan wrote: John Rudd wrote: Dennis Peterson wrote: And to follow up on the earlier point about Windows systems not being the sole source of spam/virus distribution, The idea that any platform (windows, unix/linux, etc.) attached to the net cannot be subverted into being a spam/virus zombie is, at best, naive. And a naive sysadmin is a danger to us all. I don't think anybody on this list has ever said windows can't be subverted. The swarms of compromised xp boxes that are rented out in blocks of 1000 or 1 for sending spam are proof enough of that. From reading the quotes, someone was suggesting that they're immune to compromises because they're not running windows. That statement is covered by my assertion of that idea is naive. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Memory usage for clamd is huge
Joe Sloan wrote: John Rudd wrote: Joe Sloan wrote: John Rudd wrote: Dennis Peterson wrote: And to follow up on the earlier point about Windows systems not being the sole source of spam/virus distribution, The idea that any platform (windows, unix/linux, etc.) attached to the net cannot be subverted into being a spam/virus zombie is, at best, naive. And a naive sysadmin is a danger to us all. I don't think anybody on this list has ever said windows can't be subverted. The swarms of compromised xp boxes that are rented out in blocks of 1000 or 1 for sending spam are proof enough of that. From reading the quotes, someone was suggesting that they're immune to compromises because they're not running windows. That statement is covered by my assertion of that idea is naive. I don't think they said they were immune to compromises, but that there was no compelling case for the added expense of virus scanning all outgoing mail in a non-windows environment. That's not significantly different. Just because they're in a non-windows environment doesn't mean they can't possibly be sending out viruses. The person who expressed that is, as I said, being naive. And, irresponsible. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] What's this? I can't believe it!
Gerard wrote: ... is totally unacceptable in any well organized business environment. well organized business environment?? Is that like a frictionless surface? or an ideal gas? ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Instability and Modern Anti-Virus Software
Randal, Phil wrote: [EMAIL PROTECTED] wrote: There is an article on eWeek.com today concerning instability in AV software due to the impossibility of adequately testing updates when releasing them as quickly as they are needed (www.eweek.com/article2/0,1895,2240656,00.asp?kc=EWKNLINF010208STR3). Just to force the point home, NcAfee yesterday released datfile 5197 yesterday which erroneously detected JS/Exploit-BO virus on sites like ESPN and Friendster. They've since released dat 5198 to fix the problem. The problem of false positives from bad patterns or heuristics is, IMHO, a good reason for never doing on-demand full scans of filesystems. No where near as good as Kaspersky identifying Internet Explorer as a virus, last month. When I was walking my friend through fixing it, and trying to keep her from bursting out into tears over and over again (she thought she lost her novel), it was all I could do to balance concern for her vs a desire to burst out in laughter that some AV source had finally done the right thing :-) ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Email viruses almost non-existent?
Luis Miguel R. wrote: El Monday, 24 December del 2007 a las 10:55:51AM, Dennis Peterson escribió: Paul Kosinski wrote: In December 2006, we were running ClamAV 0.88.7, and there were still a fair number of real viruses being detected in inbound email. Now running 0.91.2 and 0.92, there seem to be only phishing attempts, and not even very many of them. In fact it seems that our log file shows almost as many (hourly) signature update messages as phish detections (much less real virus detections). Have other ClamAV users experienced a similar decline in email attacks? Yes. And this can be considered bad news for clamav integrators :). Most of the viruses that I used to get are blocked by my bad-attachment-filename blocker. Block the really inappropriate stuff (.exe, .com, .bat, .pif, and a list of about 20-30 others), and the number of viruses that trickle through to clamav is amazingly small. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Xandros infringing GPL and ClamAV copyrights
I'll throw in some cash toward legal fees in pursuing the case. Let me know if it comes up, how much you need from general user contributions, and I'll see what I can contribute. Hopefully others feel the same. Stan Cunningham wrote: Hi, I'd like to inform you that Xandros has been selling a proprietary, closed source anti-virus application that is nothing more than a pretty shell to ClamAV. Importantly, the so-called Xandros Anti-Virus links to ClamAV headers, uses ClamAV resources and is a clear derivative work of ClamAV. The Xandros Anti-Virus application should therefore be licensed under the GPL. Nonetheless, the sources are nowhere to be found. I urge you to uphold your copyrights as ClamAV developers against this parasite company that has given nothing back to ClamAV or to the Linux/open source community. For more information on how to uphold your rights, please go to: http://gpl-violations.org/ http://www.gnu.org/licenses/gpl-violation.html Thanks, Stan PS: Not only is Xandros a GPL-violator when it comes to multiple FOSS projects, but they also bought into M$'s patent protection racket. Get easy, one-click access to your favorites. Make Yahoo! your homepage. http://www.yahoo.com/r/hs ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] ClamAV Vulnerability
G.W. Haywood wrote: Please either make a positive contribution or find another list on which to make trouble. He IS trying to make a positive contribution. He's trying to establish a best practice that fits for any production environment where the sysadmins care about their quality of service, and stability of features. And he's arguing for the right things. I'm certainly more interested in hearing from David, than hearing your useless prattle. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Phishing feature defaults, naming, and 0.92
rick pim wrote: who on earth upgrades from one beta to another and uses the same configfile??? Who on earth uses clamav in a way that requires a config file!? how barbaric! Any solution which only solves this problem via config file and/or command line switches is an unacceptable solution. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Accurate subjects (was Re: PhishingScanURLs is dreadfully slow/CPU-intensive)
Gerard Seibert wrote: On Monday November 12, 2007 at 01:29:41 (PM) David F. Skoll wrote: A request: When replying to an e-mail, please change the subject if it no longer reflects the thread topic. I've been eagerly awaiting word on my complaings about PhishingScanURLs from Clam developers and the misleading subjects are giving me false hope that this problem will actually be addressed... That is not going to do a lot of good. The message will still be threaded with all the other messages in that discussion. A new message should be constructed to start a new discussion when the subject changes. Out of curiosity, what is so difficult about setting 'PhishingScanURLs off' in the 'clamd.conf' file? Since the developers made that feature configurable, they have in fact addressed the issue. What if you're not accessing clamav via clamd? I don't need it to be off by default, but it'd be nice to be able to set the default setting as an argument to 'configure', since the method I use for accessing clamav doesn't let me turn it on and off (the perl module). ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Accurate subjects (was Re: PhishingScanURLs is dreadfully slow/CPU-intensive)
David F. Skoll wrote: Really? All posters on this thread who gave an opinion wanted PhishingScanURLs off by default. I invite users who want PhishingScanURLs to be on by default to come forward; I'll happily go with the majority decision. If I have to choose between on vs off, then I go with off by default. But, as I stated in another email, my true preference is default behavior set by 'configure'. And I'm agnostic about what the default for 'configure' is if you don't tell it one way or the other. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] PhishingScanURLs is dreadfully slow/CPU-intensive
Tilman Schmidt wrote: (Remember the viruses ClamAV checks for are *Windows* viruses. A unixoid OS doesn't run ClamAV for its own protection but for the protection of Windows clients.) OpenOffice isn't vulnerable to Office Macro viruses? (I honestly don't know, just asking) ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] PhishingScanURLs is dreadfully slow/CPU-intensive
Daniel T. Staal wrote: On Tue, October 30, 2007 10:15 am, David F. Skoll said: (Our customers, in fact, always run ClamAV in conjunction with an anti-spam scanner, so it's no benefit to them to have Clam try to do anti-spam.) I usually find it a detriment: ClamAV is nowhere _near_ as good at distinguishing spam/phish emails as a most spam filters, and is much more prone to false-positives in particular. So a 'spam' match from ClamAV means 'examine this file manually' whereas a spam match from a spam filter goes in the spambucket where it can be safely be ignored/deleted unless there is a reason to check it. In general, the difference between AV and AS systems tends to be that AV systems are signature based, where Spam Assassin like AS systems are heuristic based. Signature based AS systems tend to be rather accurate in terms of not having false positives, but tend to also have the vulnerability that they never catch new spam (they have to be trained for each variant of a given spam form). Signature based software, IME, also tends to be faster than heuristic based software. Heuristic software tends to be slower, but is able to detect new spam strains more effectively. IMO: it's good to have both approaches to AS in your inventory. First do signature based checks, because they're faster and should only eliminate known spam. If the signature system flags the message, then don't submit it to the heuristic system ... thus lightening the CPU overhead and average message latency imposed by the heuristic system. The problem I see with the Anti-Spam material in ClamAV is that it's not purely signature based. It tries to be a little more speculative, and in the process gives up some of the advantages of a signature based scanning method: it loses some speed (in some cases, a lot of speed), and some accuracy. But I don't see a problem with the approach in general ... I just think that if you're going to do AS work in ClamAV, you should limit it to signature based AS work, and not attempt to be heuristic about it. As for what I do when ClamAV finds spam... I have code in my ClamAV module that does this: 1) If it's spam or phishing signature, accept the message, add a header identifying the message as spam and indicating which signature was triggered. Better consistency of naming schemes for spam/phishing rules among the different signature sources could have made that easier, though. 2) If it's any other signature, reject the message during SMTP with a message indicating which signature was triggered. In practice, I haven't found the need to actually turn on #1, but the code is there. We did have one recent false positive, though (out of millions of messages scanned, even using the third party signature sources). We're discussing whether or not to turn that feature on. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] PhishingScanURLs is dreadfully slow/CPU-intensive
David F. Skoll wrote: Hello, A client of ours had a bunch of machines whose CPUs were maxed out at 100% because of clam. Changing PhishingScanURLs to no from the default yes dropped the load average from 70+ to about 3, and the CPU usage from 100% to under 50%. This is under Linux, so it's not the broken Solaris regex library at fault. I have two questions, a practical one and a philosophical one: The practical one: Do others observe the very poor behaviour of PhishingScanURLs? Is it perhaps hitting pathological cases of regex evaluation? The philosophical one: Do heuristics like PhishingScanURLs belong in a virus scanner? I realize that once the engine is in place, it's tempting to add features, but I'm not convinced such things belong in a virus scanner. I think they are more in the domain of anti-spam software, especially since it's good for security to keep your virus-scanner small, fast and secure and do more complex text analysis in a language other than C. I guess I would vote for PhishingScanURLs to be no by default rather than yes. I'm having a similar problem here. Except I can't turn it off (I'm calling clamav via perl Mail::ClamAV). But I can reliably take a message that was clogging my mail server, scan it with clamscan, and either have it completely hang without any arguments ... or have it finish almost instantly if I turn that off with a CLI argument. I would be happy to either have it off by default ... or to have the option for turning it off added to Mail::ClamAV (tried to email the maintainer, but haven't had a response). However, I _am_ experiencing this on Solaris (10, x86, on Sun Opteron boxes). I can produce 2 examples of messages that cause the problem, in RFC822 format, for anyone who wants to experiment with them. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] PhishingScanURLs is dreadfully slow/CPU-intensive
John Rudd wrote: I can produce 2 examples of messages that cause the problem, in RFC822 format, for anyone who wants to experiment with them. I decided I'd just go ahead and make them available: http://people.ucsc.edu/~jrudd/ClamAV/318642.mbox http://people.ucsc.edu/~jrudd/ClamAV/318715.mbox ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] PhishingScanURLs is dreadfully slow/CPU-intensive
Steve Holdoway wrote: On Mon, 29 Oct 2007 19:25:14 -0700 Dennis Peterson [EMAIL PROTECTED] wrote: I don't see where Linux is unique in this regard. I also don't see why the success of Linux is particularly important vs BSD, Solaris, Windows, etc. But I suppose that discussion is for another forum. dp I think the OP may beconsidering linux as a desktop. Personally, I've no problems with security in a server environment. I don't think that was dp's point. I think dp's point was that we aren't a linux forum, so a linux needs X in order to forge ahead agenda might have _some_ followers here, but it'll also get lots of yawns here. From myself included. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Does clamav protect against rootkits?
Rob MacGregor wrote: On 10/14/07, Aniruddha [EMAIL PROTECTED] wrote: Thanks for the answers, does anyone know this for sure? Quoting the ClamAV home page: ...designed especially for e-mail scanning on mail gateways. So no, it's not designed to detect rootkits. Though, it might be interesting if someone came up with a set of signatures that matched known rootkits on various platforms. It would probably turn out to be kind of a large signature database, though, just because it will have to use unique signatures for each OSxProcessor (and possibly xCompiler, and possibly x2 for static vs dynamic linking). It's not going to be something someone throws together over night, but probably would be useful to the security community in general. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Error downloading Malware sigs
Gerard wrote: Has anyone other than me been having problems download the Malware signature files for the past 24 hours? http://www.malware.com.br/cgi/submit?action=list_clamav I'm getting the errors too, both on my home machines and my work machines. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Missing Freshclam after upgrade to clamav-0.90.3-1.fc7
Steve Holdoway wrote: I think that you're falling into the all too common trap that sysadmin work is really tedious, so the top priority is to use the solution that takes the minimum time to implement, regardless of it's inherent quality. I reckon that package management is *NOT* the solution for a production server. I would modify what you've said only in that, internally generated packages are good time savers and consistency builders for a sysadmin. But, by that, I mean you build the software from source, and then build the pkg/rpm yourself, and distribute the package to yourservers yourself. That means you put into production the same package, built exactly the way you need it, built exactly the way you built on your dev machines, and tested on your test machines. But, for a professional sysadmin, dealing with mission critical servers, blindly depending upon other people's packages isn't such a great idea. Obviously this is just my opinion, and I know it's not that popular - but it's the distillation of what I have learnt the hard way over more than 23 years ( just checked my CV! ) of relevant experience. Yeah, one of the worst aspects of the open source community at large is upgrade upgrade upgrade upgrade. Just because you can, and it's free, you should. upgrade early, and upgrade often. A good sysadmin knows that that's the path of fools. Introduce new versions into your dev environment. Make sure it functions the way you want, does what you want, etc. Then package it up and install it on your test machines. Let your test machines run with it for a good solid long time (weeks). Enough to _prove_ it does what you want/need it to when under load, etc.. Then you have to wait for a window when you can make a change to your production service environment without it undermining your service. For me, that window happens at the end of each academic quarter (after finals, after grades are due the following Tuesday, THEN I can make changes). So, if a new version of software comes out in September, I wont be deploying it until December. Chances are, if a new version comes out in late November or early December, I wont put it into production until late March (spring break) ... because late November isn't enough time for me to put it through its paces and deploy it in mid/late December. (as a non-strict rule of thumb, I would estimate that for me to deploy in December, it would have to be released no later than October) So, I see people who upgrade production mission critical systems to new versions of a software package within 2 days as just being quite a bit insane and reckless. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Missing Freshclam after upgrade to clamav-0.90.3-1.fc7
Graeme Nichols wrote: Anyone any ideas please? Build and install from source? ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] signature names
(to the developers, not in answer to Burnie) See, the current name scheme needs to be fixed. And no one responded at all to my proposed scheme from a month or two ago. Burnie wrote: Just a bit curious - what classification is this signature? I can't find this naming scheme mentioned somewhere. ClamAV database updated (11 Sep 2007 19-32 +): daily.cvd Version: 4244 Submission-ID: 1710033 Sender: rafael Added: Email.Foolball-2 - The reason I'm asking is that I have to distinguish between spam/pishing and viruses and are doing this by the signature name. A prefix of 'Email' just won't give any clues, I already knew it was an email :) ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] signature names
Andy Fiddaman wrote: On Wed, 12 Sep 2007, Karsten Bräckelmann wrote: ; On Wed, 2007-09-12 at 07:28 -0700, John Rudd wrote: ; (to the developers, not in answer to Burnie) ; ; See, the current name scheme needs to be fixed. And no one responded at ; all to my proposed scheme from a month or two ago. ; ; Coincidentally, my very first question on this list years ago was about ; naming conventions (or the lack thereof), too. :) It's not just core Clam signatures either, SaneSecurity recently changed the capitalisation on some of their sigs which caused me a few issues (I'm checking case-insensitively now!) The same thing happened when Phishing.Email changed to Phishing.Heuristics.Email on 29/6. Standardising prefixes would be excellent for those of us who make decisions based on what's coming back. Yup. Caused me an issue too. Suddenly I had an unexpected source of virus signatures in my metrics. I didn't appreciate that at all. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] signature names
Dennis Peterson wrote: Karsten Bräckelmann wrote: On Wed, 2007-09-12 at 07:28 -0700, John Rudd wrote: (to the developers, not in answer to Burnie) See, the current name scheme needs to be fixed. And no one responded at all to my proposed scheme from a month or two ago. Coincidentally, my very first question on this list years ago was about naming conventions (or the lack thereof), too. :) karsten That probably means names are really not all that important in the big picture. ... There are much more important things to be concerned with than what a virus is called. You're awfully cavalier about what's important to other people's email. The fact that they're not important to you does not mean that they are unimportant. For example, under my proposed scheme, I could easily decide to: 1) reject viruses during SMTP 2) accept, but hold in quarantine, messages matching phishing sigs 3) accept, but mark as possible spam, messages matching spam sigs (and possibly even rating the likelihood of spam based upon a false-positive reputation score for the given signature source) But, without a coherent and explicit name convention, the rules for doing so would be so complex as to be not be worth the effort in writing them. In some cases, it's even ambiguous as to which of the above categories a given message falls in to. The only people dismissing the name convention as unimportant are people who aren't paying attention to the bigger picture (in that they're only looking at what's important in their own part of the picture). I'll even volunteer some of my time to help develop the name scheme (I've already put one such scheme forward), and to help re-organize the signatures that are already out there. I'm not just complaining, I'm offering to be part of the solution. Yet, all I've gotten on this, until today, is total silence. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] signature names
Kelson wrote: John Rudd wrote: But, without a coherent and explicit name convention, the rules for doing so would be so complex as to be not be worth the effort in writing them. In some cases, it's even ambiguous as to which of the above categories a given message falls in to. Or, alternatively, a piece of metadata associated with each signature that indicates its category, which is returned as part of the results. Advantage: conceptually cleaner than messing with the name. Disadvantage: need to change calling methods to handle another return field; need to decide on categories; will eventually need to add categories. I would be fine with a metadata solution, but part of that information is clearly already being put into the virus name; if you start to put it into metadata, then the virus name might as well just be a number. And, the infrastructure for getting that metadata should be very easy to work with (a well documented argument to clamscan/clamdscan, a well documented set of calls into libclamav, and a well documented set of calls into the various scripting interfaces to clamav). ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] MBL?
Did something happen to the MBL signature source? yesterday my automated script got all errors for the download content, and today it's complaining about it not existing. Is it as simple as the URL changing? or did it go away entirely? ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] clamd load spikes
Is anyone seeing a surge clamd loads today? Or has everyone upgraded from 0.88.6 and 0.91.2 doesn't have the problem anymore? ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] As soon as Sourcefire starts charging for virus updates,
Sergei Lavrov wrote: people will stop contributing signatures, right ? Or they'll start contributing more to the 3rd party signature databases, instead (MSRBL, MBL, SaneSecurity, etc.). If the engine is free, but the signatures aren't, you don't need to go to Sourcefire for your signatures. If the engine stops being free, then we can all fork off a free version of the engine based upon the last open-source version. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] clamav 0.91.2 is out. Don't use it.
It has a dangerous (lack of) value for CL_SCAN_STDOPT. You're better off not upgrading until they fix it. (filed as bug 631, but it's nothing new: CL_SCAN_STDOPT still doesn't include CL_SCAN_PHISHING_DOMAINLIST; that omission can cause crashing and hanging on certain platforms ... the clamav team already knows about this problem, and they even enable that option as a default in clamscan, just not in the CL_SCAN_STDOPT defined value ... my suggestion is to not upgrade until they release a version that fixes this problem) ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] clamav 0.91.2 is out. Don't use it.
Tilman Schmidt wrote: John Rudd schrieb: (filed as bug 631, but it's nothing new: CL_SCAN_STDOPT still doesn't include CL_SCAN_PHISHING_DOMAINLIST; that omission can cause crashing and hanging on certain platforms ... the clamav team already knows about this problem, and they even enable that option as a default in clamscan, just not in the CL_SCAN_STDOPT defined value ... my suggestion is to not upgrade until they release a version that fixes this problem) Browsing the source, I see that clamd also sets this by default, and would even emit a log message: Phishing: Checking all URLs, regardless of domain (FP prone).\n if overridden by the PhishingScanURLs option in clamd.conf. So am I correct in assuming that clamd isn't vulnerable as long as that warning message does not appear in the log, and that users of either clamd or clamscan can upgrade without fear? Let me clarify. My statement to not upgrade isn't mainly on the point of safety. My statement is because the clamav team have known about this problem for a while, and continue to do nothing about it. I'm saying don't upgrade until they fix this easy to fix, but very troublesome, issue. Some specifics: - the problem is in using libclamav, not in using clamd nor clamscan. For example, if you're using the Mail::ClamAV perl module, you've got to worry about this problem. - the platform _I_ have experienced the problem with is solaris 10 x86, but when I was figuring out the source of the crashing, it was pointed out to me by someone else, and the inference was that this happens on more than just my platform. Though, I can also state that I haven't seen the problem on Mac OS X on PowerPC, where I use the exact same code base. - the problem would be trivial for them to fix, it's just a one line change in clamav.h ... all that has to be done is a simple change to include CL_SCAN_PHISHING_DOMAINLIST in the definition of CL_SCAN_STDOPT - there's also the simple issue of orthogonality (as in orthogonal instruction set) in the feature set. The default behaviors should be the same across the spectrum of interfaces to the clamav functionality. - clamscan: the default behavior implies CL_SCAN_PHISHING_DOMAINLIST - clamd: the default behavior implies CL_SCAN_PHISHING_DOMAINLIST - libclamav: the default does NOT imply CL_SCAN_PHISHING_DOMAINLIST Thus, the choices for accessing clamav's virus detection functionality are NOT orthogonal. This is, IMO, a design flaw. And, as I said, an easy to fix design flaw. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Sourcefire acquires ClamAV
James Kosin wrote: Tomasz Kojm wrote: Ed Kasky wrote: Tomasz Kojm wrote: lead the advancement of ClamAV and the CVD as employees of Sourcefire. Both the ClamAV engine and the signature database will remain under GPL. Until they start charging for current updates, etc. like they do with Snort... you should rest assured that the virus database will stay GPL and will be distributed the same way as so far, Sourcefire has no intention of changing this. I'm complaining now... because the virus database is not the source to build the binaries. If hey are only saying the virus database is the ONLY part to stay GPL we may have to pay through the nose for the source to build the compiled binaries! I'm HOPING this hasn't happened and you mis-typed your reply. The original email said that BOTH would remain under the GPL. However, there's nothing about the GPL that prevents them from charging money. GPL is free as in speech, not free as in beer or lunch. After all, I made a nice chunk of change working for a company that made free software expensive (Cygnus with gcc/gdb). On the other hand, if sourcefire starts to charge money, there's nothing that would prevent the community from starting a new distribution of the codebase, either. I don't exactly blame the ClamAV team for doing this. It's entirely within their rights, and it has been nice that they've had ClamAV out there in the form it has been for all of this time ... but it was also nice to have a non-corporate driven AV solution out there, especially one that had the solid reputation of ClamAV. No matter what sourcefire does with the project, completely free or subscription driven, etc., the fact is that ClamAV isn't the same starting today. It's now just another AV product, instead of a community project. That's kind of sad. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Sourcefire acquires ClamAV
Mike Guiterman wrote: Q. When will Sourcefire begin to integrate ClamAV technology into its products? A. Sourcefire intends to offer support and training services to ClamAV users beginning in Q4 2007. We anticipate offering products based on ClamAV as a part of our Enterprise Threat Management product family in the latter half of 2008. So, it may take the MIMEDefang approach? Where Can-IT is a commercial product that includes MIMEDefang at its core, and MIMEDefang is, and remains, a free (both speech and beer/lunch) project? (I hope David, who is also on this list, doesn't mind me using him as an example) That would be very encouraging. I wouldn't mind that at all. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] phishing header matches
Scott Beck wrote: Hi, Another note on this issue. Someone just reported that without the CL_SCAN_PHISHING_DOMAINLIST option set they are seeing libclamav hang. Please consider adding this to CL_SCAN_STDOPT or remove the option and turn it on internally always or reverse the option and have something like CL_SCAN_PHISHING_NODOMAINLIST. Yup. That'd be me. (thanks for re-reporting it here, Scott; and thanks for your help figuring it out) On the one hand, tracking this down helped me learn a lot more about ClamAV, and the various options... I was able to refine and streamline my code quite a bit, and eliminate various things I didn't actually need to do. But ... for all that I value learning experiences, I would like to strongly make one statement: The default behavior of clamscan should match the standard options. If clamscan/clamdscan, by default, does CL_SCAN_PHISHING_DOMAINLIST, then that should be in CL_SCAN_STDOPT. Anything else that clamscan/clamdscan do by default should also be in CL_SCAN_STDOPT. Anything that clamscan/clamdscan don't do by default should NOT be in CL_SCAN_STDOPT (though I don't think anything falls into that category). If you're going to not add CL_SCAN_PHISHING_DOMAINLIST to CL_SCAN_STDOPT, then stop having clamscan/clamdscan use it by default. Make it a command-line option. (though, my recommendation is: add CL_SCAN_PHISHING_DOMAINLIST to CL_SCAN_STDOPT ... I agree with Scott that it's a useful and necessary function) ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] (not-exactly-a-Feature) Request
Identifying the exact nature of a signature, just from the name, is a
major pain. Especially when you throw in the 3rd party signatures. The
location in the signature name of the authority it came from varies from
group to group (and isn't present in the ClamAV signatures at all).
Whether it's virus/malware/trojan/worm or just a phishing/fraud or spam
signature is handled differently by each authority. It's just a _MESS_,
on the part of _ALL_ of the signature authorities, including ClamAV's
official signatures.
I'd like to see better organization on this front. My suggestion is:
A signature name is a dot separated 4-tuple or 5-tuple, with the
following fields:
- the first field is the signature source:
ClamAV, Sanesecurity, MBL, MSRBL, etc.
- the second field is the signature category:
Virus, Worm, Malware, Trojan, Exploit, Scam or Fraud or Phishing,
Spam, Archive, etc.
- the third field is the platform/mechanism abused:
Win32, MacOSX-x86, MacOSX-ppc, Linux-x86, Solaris-x86,
Solaris-Sparc, FreeBSD-x86, NetBSD-x86, NetBSD-all,
Image, PDF, MS-Macro, HTML, Zip, etc.
- the optional fourth field is a signature sub-category
Stock, Spyware, virus-family-name, etc.
- the last field is an exact signature ID
Further, the first 3 fields would need to be universally agreed upon
(dictated by ClamAV, IMO).
So, this: Email.Stk.Gen588.Sanesecurity.07071604.pdf
becomes: Sanesecurity.Spam.PDF.Stock.Gen588-07071604
This: Worm.Mydoom.M
becomes: ClamAV.Worm.Win32.Mydoom.M
This: HTML.Phishing.Bank-3
becomes: ClamAV.Fraud.HTML.Bank.3
or: ClamAV.Phishing.HTML.Bank.3
This: Zip.ExceededFilesLimit
becomes: ClamAV.Archive.Zip.Exceeded.FilesLimit
(which might also mean there'd be ClamAV.Archive.Zip.Exceeded.Size
ClamAV.Archive.Zip.Encrypted or even ClamAV.Archive.Rar.NotAllowed, if
all rar files are blocked)
This would make it a LOT easier to decide how to handle a given match in
a programmatic manner. For example, if I have a sendmail-milter and I
want to reject viruses, worms, and malware, but I want to merely mark a
header for things like Phishing/Fraud Scams or Spam, I could do
something like:
if ($virusname =~ /\.(Scam|Fraud|Spam)\./) {
add_a_header_and_accept();
}
else {
send_smtp_5xx_response();
}
Or, perhaps I want to do it by signature authority, because I've heard
some signature authorities might have false positives:
if ($virusname =~ /^ClamAV\./) {
send_smtp_5xx_response();
}
elsif ($virusname =~ /^Sanesecurity\./) {
do_sanesecurity_action();
}
elsif ($virusname =~ /^MBL\./) {
do_mbl_action();
}
elsif ($virusname =~ /^MSRBL\.) {
do_msrbl_action();
}
else { # some new signature authority I haven't specifically handled yet
add_a_header_and_accept();
}
The point is, whether you go with my suggestion or some other idea,
imposing _SOME_ kind of structure on the signature names is, IMO,
necessary. It needs to be formalized, and required of all signature
authorities. When someone wants to add a new possibly value to the
first 3 fields of the tuple, I'd suggest that it have to be blessed by
some group (the clamav developers? a side-group with some of the clamav
developers and some of the other authority members, whatever).
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Greeting Card virus
Jeff Thurston wrote: Jeff Thurston wrote: I thought ClamAV was able to catch these Greeting Cards from family member, our domain keeps getting these emails in large quantities even after upgrading to ClamAV 0.90.3 recently. Do I need to upgrade again to .91?? I'm hesitant to do this so soon as it was a bit of a hassle going from 0.88.4 to 0.90.3, not to mention at the time I did the upgrade the website front page said that ClamAV was one of 4 scanners able to detect the virus. Did I misunderstand that statement thinking it meant both the downloaded payload as well as the email its self? What can I do with ClamAV to stop the emails in the first place? Thanks. Get the highly regarded sane signatures: http://sanesecurity.co.uk/clamav/ Look under Usage for download scripts. MrC ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html Thanks, done this, tested it, still getting greeting cards, enabled URL scanning, still getting them, checked my main database version, it's reporting ClamAV 0.90.3/3700/Thu Jul 19 06:13:47 2007 main.cvd is up to date (version: 43, sigs: 104500, f-level: 14, builder: sven) daily.inc is up to date (version: 3700, sigs: 34427, f-level: 16, builder: ccordes) main.cvd is up to date (version: 43, sigs: 104500, f-level: 14, builder: sven) daily.inc is up to date (version: 3700, sigs: 34427, f-level: 16, builder: ccordes) That report doesn't include the sane security files. Where did you put phish.ndb and scam.ndb? You didn't leave them gzipped, did you? ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] automated response
Christopher Checca wrote: I will be on vacation until July 30, 2007. Think his house is unoccupied? Maybe we can throw a party ... ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Third party signature databases
From past discussion on this list, it was discussed how easy it would
be to throw together a script to check validity before putting a message
into production. But I don't recall anyone ever actually offering up
their script. Earlier today, someone had posted something to the
SpamAssassin list that showed they weren't properly handling downloaded
signature databases, and it just so happens that I just got around to
writing such a script the other day.
So I thought I'd post it here for review/criticism/distribution.
One note: the reason I use the %destdirs hash, even though they're all
the same destination, is that I plan in the future to use multiple
instances of Mail::ClamAV running from different directories, each with
a different source of signatures. Right now it's 1 clamd running with
all of the sigs, though, so it's all 1 destination.
Also, be careful of line wraps caused by email... I'll try to put this
up on a web page in the nearish future.
---
Here's the script I use for importing from MSRBL and Sanesecurity. I
run it out of cron with -all, on the hour. You'll probably need to
modify some bits of the first few lines (down to the rsync binary location):
#!/usr/local/bin/perl
my $chmod = /bin/chmod;
my $mv = /bin/mv;
my $gunzip = /usr/bin/gunzip;
my $clamscan = /usr/local/bin/clamscan;
my $testfile = /bin/sh;
my $diff = /usr/bin/diff;
my %methods =
(http = /usr/local/bin/wget -q,
rsync = /usr/bin/rsync -q);
my %urls =
(msrbl-spam = rsync://rsync.mirror.msrbl.com/msrbl/MSRBL-SPAM.ndb,
msrbl-imgs =
rsync://rsync.mirror.msrbl.com/msrbl/MSRBL-Images.hdb,
sane-phish =
http://www.sanesecurity.com/clamav/phishsigs/phish.ndb.gz;,
sane-scam =
http://www.sanesecurity.com/clamav/scamsigs/scam.ndb.gz;);
my %tmpdirs =
(msrbl-spam = /tmp/msrbl,
msrbl-imgs = /tmp/msrbl,
sane-phish = /tmp/sanecomputing,
sane-scam = /tmp/sanecomputing);
my %destdirs =
(msrbl-spam = /var/lib/clamav,
msrbl-imgs = /var/lib/clamav,
sane-phish = /var/lib/clamav,
sane-scam = /var/lib/clamav);
my $getall = 0;
my (@distros, $dist, $tmpdir, $proto, $method, $file, $retcode);
my ($ufile, $diffout, $destdir);
if ($ARGV[0] =~ --?al?l?) {
$getall = 1;
@distros = keys(%urls);
}
else {
@distros = @ARGV;
}
foreach $dist (sort (@distros)) {
$tmpdir = $tmpdirs{$dist};
$destdir = $destdirs{$dist};
$url = $urls{$dist};
$proto = $url; $proto =~ s/:.*$//;
$method = $methods{$proto};
$file = $url; $file =~ s^.*/([^/]*)$$1;
$ufile = $file; $ufile =~ s/\.gz$//;
if ((-e $tmpdir) (!(-d $tmpdir))) {
rename ($tmpdir, ($tmpdir . .bad))
|| die tmpdir $tmpdir isn't a directory, can't rename it;
mkdir ($tmpdir) || die can't make tmpdir $tmpdir;
}
elsif (! (-e $tmpdir)) {
mkdir ($tmpdir) || die can't make tmpdir $tmpdir;
}
system ($chmod 700 $tmpdir);
if ((-e $destdir) (!(-d $destdir))) {
rename ($destdir, ($destdir . .bad))
|| die destdir $destdir isn't a directory, can't rename it;
mkdir ($destdir) || die can't make destdir $destdir;
}
elsif (! (-e $destdir)) {
mkdir ($destdir) || die can't make destdir $tmpdir;
}
system ($chmod 775 $destdir);
chdir ($tmpdir);
if (-e $file) {
unlink ($file);
}
if (-e $ufile) {
unlink ($ufile);
}
# download the file
if ($proto eq rsync) {
system($method $url $file);
}
elsif ($proto eq http) {
system($method $url);
}
unless (-e $file) {
printdidn't get download file $file\n;
last;
}
if ($file =~ /\.gz$/) {
system($gunzip $file);
$file = $ufile;
}
# test against clamav
$retcode =
system($clamscan --database=$tmpdir $testfile /dev/null 21)
/ 256;
if ($retcode == 0) {
# clamscan of testfile worked and didn't find a virus
# lets see if it's the same file we already have/had
$diffout = (system($diff --brief --speed-large-files
$tmpdir/$file $destdir/$file /dev/null 2/dev/null)) / 256;
if ($diffout == 0) {
# file hasn't changed
unlink ($file);
}
else {
print$file appears to have changed, moving to destination\n;
system($mv $tmpdir/$file $destdir/$file);
system($chmod 644 $destdir/$file);
}
}
elsif ($retcode == 1) {
printfound a virus in $testfile while testing $dist\n;
}
else {
printnew $dist download appears to be corrupt\n;
}
}
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Third party signature databases
Noel Jones wrote:
At 12:59 PM 7/12/2007, John Rudd wrote:
From past discussion on this list, it was discussed how easy it would
be to throw together a script to check validity before putting a message
into production. But I don't recall anyone ever actually offering up
their script. Earlier today, someone had posted something to the
SpamAssassin list that showed they weren't properly handling downloaded
signature databases, and it just so happens that I just got around to
writing such a script the other day.
You must not be following the list very closely. Such scripts have
been posted frequently and several good ones are available from
http://sanesecurity.co.uk/clamav/usage.htm
The last time I saw it come up on this list, I didn't see a script come
back within a few days. If it took longer than that, I probably was
only skimming the list by then (my degree of intently reading vs
skimming the list varies over time, but when there's a thread I
consider important I try to keep up with it until it looks like the
thread has petered out ... and the download script with verification
that the database is usable by clamav is an important topic to me).
I saw the supporting material on sanesecurity's downloads page, but it
looked like it was almost all windows oriented (ie. useless to me).
Plus, I want one thing that I can apply to all 3rd parties, and I
(perhaps incorrectly) assumed sanesecurity's stuff would be oriented
just around their own stuff.
Also, if you check the Sanesecurity usage page, you will note
download signatures only when there have been changes, which your
script seems to ignore. Use the wget -N option.
Also, it looks as if you are removing your tmp files every time the
script runs. This causes rsync to download the whole file rather
than checking for changes, and makes it impossible for wget -N to work.
Yes, I am/was aware that I'm undermining rsync's bandwidth savings. I
just hadn't figured out the best way to address that. I don't think
that leaving it in /tmp/{something} works well for that. I had been
thinking about doing the scratch space in
/usr/local/share/{something}/tmp, but wasn't sure if that would be
standard enough.
I suppose I could put it under {clamavdbdir}/{source}/tmp
And, it was this types of reason I wanted to open it up for public scrutiny.
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Third party signature databases
Noel Jones wrote:
At 02:02 PM 7/12/2007, John Rudd wrote:
Such scripts have
been posted frequently and several good ones are available from
http://sanesecurity.co.uk/clamav/usage.htm
I saw the supporting material on sanesecurity's downloads page, but it
looked like it was almost all windows oriented (ie. useless to me).
There are 5 scripts on the page, only the last one is labeled as a
windows script.
Plus, I want one thing that I can apply to all 3rd parties, and I
(perhaps incorrectly) assumed sanesecurity's stuff would be oriented
just around their own stuff.
All those scripts are clearly labeled as working with MSRBL.
Like I said, what I looked at was their downloads page.
Their downloads page has:
1) their phishing signatures
2) their scam signatures
3) a windows installer for their phishing signatures
4) a windows installer for their scam signatures
5) a build of clamav for windows
6) a signature updater that doesn't give a platform, but is from the
same source as #5
7) rsync for windows
89) references to MSRBL signatures
So, as I said: the only specifics of the page I looked at, before you
made me aware of their usage page, were windows specific, and the
installers were also highly specific.
Yes, I am/was aware that I'm undermining rsync's bandwidth savings. I
just hadn't figured out the best way to address that. I don't think
that leaving it in /tmp/{something} works well for that. I had been
thinking about doing the scratch space in
/usr/local/share/{something}/tmp, but wasn't sure if that would be
standard enough.
Consensus seems to be that /var/tmp/clamdb or similar is an
appropriate place to hold the scratch/work files.
checking for updates every hour is wasteful, every 4 hours is more reasonable.
noted.
Here's a perl one-liner you might want to integrate in your script
- it signals clamd to reload the database. Only run this if one of
the databases has changed.
# perl -MIO::Socket::UNIX -we 'my $s = IO::Socket::UNIX-new (shift);
$s-print(RELOAD); print $s-getline; $s-close'
/var/run/clamav/clamd.socket
When I switch to the Mail::ClamAV method, it has a means of detecting
and reloading as necessary. I'm doing that this week.
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] clamscan extremly slow
Jan-Pieter Cornet wrote: On Mon, Jun 18, 2007 at 09:39:23AM -0400, Christopher X. Candreva wrote: On Mon, 18 Jun 2007, Peter Boosten wrote: I had some problems running clamd on one of the machines a long time ago, and with mimedefang running clamscan is the second option (which had worked until sometime ago). So I configured mimedefang for clamscan. Maybe it's time to ask the mimedefang people to either remove the clamscam option, or put a big NOT FOR PRODUCTION - FOR TESTING ONLY on it. clamscan has a purpose. As others have also said - YMMV. A very lightly loaded mailserver (~100 msgs/day) shouldn't have a lot of problems with clamscan. At least not with the 0.88.x version. That, or mail servers that scan their email in bulk batches (like those using mailscanner), where the latency of starting clamscan is MUCH smaller than the latency in going through clamd (I've timed both under mailscanner and mimedefang; under mimedefang, using clamd is a HUGE win, as everyone here expects ... under mailscanner, using clamd is a HUGE loss). Though, the fastest method, for mailscanner, is using the ClamAV perl module for directly processing the messages. This wasn't much of a win under mimedefang though. So the real answer here is, as with any non-trivial discussion: it depends. It depends on what you're doing, and how you're doing it. Batching: look toward clamscan or the ClamAV perl module and away from clamd. Interactive/live (such as a milter): look toward clamd. Ultimately, if it _REALLY_ matters to you, don't listen to other people's dogma, actually develop a test suite to figure out which one is truly faster or slower for your situation. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] clamscan extremly slow
Henrik Krohns wrote: On Mon, Jun 18, 2007 at 10:45:30PM -0500, Eric Rostetter wrote: if you have sufficient system resources, and are willing to tolerate slow delivery times (up to 4 minutes on my system, with clamscan on 0.90.3 for example). I'm just amazed by all the nitpicking in this thread. If you worked here and delayed the mail for 4 minutes just because clamscan works fine, I would fire you. :D Nothing personal ofcourse. heh. Nitpicking indeed. If I were working somewhere that was so clueless about how email works that 4 minutes delay was considered unacceptable*, then I'd quit. Nothing personal, I just don't feel it's worth my time to work for people who don't understand how email works. (* questionable? not idea? sure.. unacceptable to the point of firing someone? that's incompetent management) ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] error stops clamd
As more users upgrade from 0.8 to 0.9, this problem will disappear with future updates. Version 0.9 only transfers the difference between CVDs instead of the files in full. Which isn't going to happen, at least for me, until 0.9 runs on mac os x 10.3.9. Right now, it wont compile. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] error stops clamd
Dennis Peterson wrote: You need to have better monitoring and notification, and a mail system that delivers mail even if there is a fatal error in the AV tool. This is hardly a ClamAV problem. Depends on what your goals are. For me, a reliable email system does not just mean mail gets delivered. It also means that we reliably reject detectable viruses. If we're letting viruses through because our pants are down (because our AV tool has failed), then that's not a reliable email system. That's a dysfunctional email system. better monitoring and notification: yes, good. letting potentially virus laden email through because your AV tool is down: very bad. It's like using condoms. Just because you run out of condoms doesn't make unprotected sex suddenly safe. Accepting email from the world without your AV tool processing it is as irresponsible as having unprotected sex with the entire world. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] error stops clamd
Dennis Peterson wrote: John Rudd wrote: Dennis Peterson wrote: You need to have better monitoring and notification, and a mail system that delivers mail even if there is a fatal error in the AV tool. This is hardly a ClamAV problem. Depends on what your goals are. For me, a reliable email system does not just mean mail gets delivered. It also means that we reliably reject detectable viruses. If we're letting viruses through because our pants are down (because our AV tool has failed), then that's not a reliable email system. That's a dysfunctional email system. better monitoring and notification: yes, good. letting potentially virus laden email through because your AV tool is down: very bad. Send it to your next AV tool. You don't rely on a single tool for this, do you? A single virus detecting program? No. A single decision point about deliver vs reject vs tempfail? Yes. (and, AV tool to me means all of these programs collectively (sophos, clamav, and/or mcaffee as the detection programs, and mailscanner or mimedefang or some other milter as the decision maker) If, at the point of making the decision of should I deliver? I have not gotten a definitive answer to is this message clean? then it would be very bad to go with deliver. There is no next tool to pass the decision on to, because at that point all of the available detection programs have answered. So, when you say You need to have a mail system that delivers even if there is a fatal error in the AV tool, I say: no. A fatal error means that the collective tool hasn't been able to determine whether or not the message contains a known infection (no matter how many detection programs I'm running). Therefore, we tempfail it. I do not see any other available and acceptable outcome. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Does clamav have any certificate?
Randal, Phil wrote: Does clamav have any certificate of any labs like www.icsalabs.com? And how does that make it a better product, exactly? Who said anything about a better product? Certification doesn't indicate a better product. It indicates either that someone has shown that it has compliance with a given standard OR that some agent has done some assessing reliability/accuracy/etc. of the product and put their name/reputation forward as an assurance of that assessment. The reason why the latter might be useful is when doing due diligence in designing a project, so that the sponsors/customers of the project know that the elements of the project aren't being taken on a whim. It may also allow you to offload liability, to some degree, on some outside agent. Obviously, it's better to get your certifications from reputable agents than not, since the value of the certification is based upon the reputation of the certification agent. Not very useful to hobbyists or computer scientists (where due diligence takes a back seat to more technical issues), but very useful to professionals and engineers (where due diligence should be a high priority). ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Compiling 0.90.1 on Mac OS X Server 10.3
Dana Kashubeck wrote: I am not able to compile the latest stable version on Mac OS X Server 10.3. There are a few different warnings here and there, most of them are shown while compiling unrar.c: ... The compile ends with: /usr/bin/libtool: no library created (no object files in input files) make[1]: *** [libclamav.la] Error 1 make: *** [check-recursive] Error 1 Is anyone else having problems on Panther? Yup, same exact problem. I notice no one replied to your question. Did you get it resolved? Seems like, from reading this list, so far ClamAV 0.90.* is pretty much a disaster. I don't think I'm aware of anyone having a smooth experience with it. Can anyone out there contradict that? Especially on Mac OS X 10.3.9 and/or Solaris 8? ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] [Fwd: [clamassassin-announce] Problems with ClamAV 0.90 and clamassassin 1.2.3]
Tomasz Kojm wrote: On Wed, 21 Feb 2007 12:16:02 -0500 (EST) Daniel T. Staal [EMAIL PROTECTED] wrote: Dear clamassassin users, There is a compatibility problem when using clamassassin 1.2.3 with the new ClamAV 0.90 release. The new ClamAV release has changed some of the command line options, and one of these changes makes clamassassin not work correctly when using clamscan. However, using clamassassin with clamdscan doesn't seem to have any problems. Now clamscan can scan email messages without any special options This was the case already in 0.8x, in fact --mbox was being ignored since 2004: The difference is that in 0.9 it's not ignored. It's rejected. --mbox produces an error. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] automatic version update
Dennis Peterson wrote: Erez Epstein wrote: Hello, I see that about every month, there is new version, what does one do when it has about 30 servers, that need to be updated? is there an automatic way? all servers have compiled versions of clamav. I use Cfengine. All updates happen within 30 minutes regardless of how many systems you have to update. cfengine has a built in script for downloading only the most recent clamav (and not re-downloading an existing one), building it, and installing it? ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] automatic version update
Dennis Peterson wrote: John Rudd wrote: Dennis Peterson wrote: Erez Epstein wrote: Hello, I see that about every month, there is new version, what does one do when it has about 30 servers, that need to be updated? is there an automatic way? all servers have compiled versions of clamav. I use Cfengine. All updates happen within 30 minutes regardless of how many systems you have to update. cfengine has a built in script for downloading only the most recent clamav (and not re-downloading an existing one), building it, and installing it? Cfengine will do what ever you tell it to do. It is a framework but you fill in the details. There are no turnkey solutions for solving arbitrary data center needs - only tools. Cfengine is one such tool. One could also write a script to do this, but Cfengine is already running here so why not use it? Yes, I know what cfengine is, and what it does. My point was simply saying I use cfengine doesn't answer the question being asked UNLESS it comes with the full solution ready to go. It is like being asked Does anyone here know where to get a 5 cheese lasagna?, and you answered I eat food. Great ... but not really a useful answer. At this point I've not installed anything myself [...] While I wasn't the original poster, the need I see in this arena isn't really filled by what you've described. And I disagree that you haven't installed anything yourself. You installed it in the cfengine repository. The fact that that isn't the final destination for the binary is splitting hairs about what it means to install the software. What I'm looking for is pretty much what I mentioned: I want something that will check if there's a new source distribution (tar, not rpm), download it, config it against some set parameters, build it, and run some post-build scripts (which may or may not include: test it against some known routines, inform me that a new binary is built and ready, and/or go ahead and install it on my non-production servers). I could write some of it, but the fact that there isn't a simple and consistent http://some.site.net/some/path/clamav-current.tar.gz; url makes that a lot more complex. The url includes the version number, which means you need to know what the next version number will be before you look to see if its there (and simple incrementation may or may not work ... for example, if I'm on 0.88.7 ... then the program may be looking for 0.88.8 to come out ... but it looks like the next version will be 0.90 ... so the program is going to sit there looking for something that never arrives). The easiest thing would be if clamav always had a clamav-current to download. Writing the rest would be easy. And then there would be a simple answer to Is there an automatic version update utility, because I use cfengine is not that answer. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] automatic version update
Dennis Peterson wrote: Any tool anyone can suggest comes with the implication that some local effort is going to be required. Nobody has yet written the magic.sh script that can run autonomously, scan your network, and decide on it's own what needs to be done. Sticking to talking about a magic.sh that installs the latest version of an anti-virus engine ... There is in fact such a tool for Sophos (through mailscanner). mailscanner comes with sophos-autoupdate (which is the same idea as freshclam)... but then there's an add on called MajorSophos.sh, which downloads and installs the current engine. I have it run against my test server a 10 days before I have it run on my production servers. It throws out any warnings, I get 10 days to hear if anyone else has a problem with the new version (20 really, since they tend to come out on the 1st, and cron runs the script on the 10th). And at any time I can stop the update from running on the production servers. And that's basically the setup I want to have with ClamAV. I want a MajorFreshclam that has: A) exploration mode (to be run on a test server, via cron) 1) check on the state of what the current version of clamav is, 2) if there's a new stable release: shut down the current one, download it, config it, build it, try to reconcile config files (take known settings from the old config file and put them into the new config file, report on new/unexpected config file items), install it on the test servers 3) optionally forcibly re-installs (from downloading to local, or via CPAN) the current/newest perl module 4) run tests 5) mail me the output of 1-4 B) blessing mode (to be run on the test server, manually) - have a command line option for pushing the new executables and config files into whatever my central distribution mechanism is. A single step 'install' from build location to repository. C) production mode (run on production servers, via cfengine or cron) 1) looks in a local distribution point for a new version 2) halts the old version, installs the new version, starts the new version 3) optionally forcibly re-installs the current/newest perl module (from local distribution point, or from CPAN -- configurable) D) a less safe mode that basically combines A and C, and skips B. But include lots of warnings about using this mode. And, I'm happy to _write_ such a beast. I'm not just requesting it from someone else. I'm just saying, that's what the OP's request brings to my mind. The main thing that keeps me from writing it is: that lack of a -current copy of the download archive. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] automatic version update
Fajar A. Nugraha wrote:
John Rudd wrote:
And, I'm happy to _write_ such a beast.
Very good!
I'm not just requesting it from someone else. I'm just saying, that's
what the OP's request brings to my mind. The main thing that keeps me
from writing it is: that lack of a -current copy of the download
archive.
Assuming what you mean is something like
http://some.site.net/some/path/clamav-current.tar.gz;, as you said in
the previous post, there's :
- http://www.clamav.net/snapshot/clamav-devel-latest.tar.gz, for the
development version
- The DNS record current.cvd.clamav.net, for stable version.
What I did for stable version is use something like this :
VERSION=`host -t txt current.cvd.clamav.net | gawk -F \ '{print $2}' |
gawk -F \: '{print $1}'`
wget
http://optusnet.dl.sourceforge.net/sourceforge/clamav/clamav-$VERSION.tar.gz
Choose your favorite SF mirror, of course.
There are some configuration file (clamd.conf, mostly) syntax change in
0.88 - 0.90, so the above example might not be useful for such
transition. It would be useful for 0.88.7 - 0.88.8 (should it ever come
out) and 0.90 - 0.90.1 (in the future)
ooh! That is a good resource. Thank you!
Do you know what the other fields in the TXT record mean?
Thanks!
John
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Why does clam die on a malformed database ?
Christopher X. Candreva wrote: On Sat, 30 Dec 2006, Sander Holthaus wrote: There is no point in using a malformed database and could even spell disaster. (Imagine it starts generating FP's en masse, which could be a side effect of a corrupted database). Having clam die spells disaster. If you've set your system to tempfail on clam failure, you can't receive mail until it is fixed. If you accept mail unscanned, you could infect your users, start spreading viruses, and have a big clean-up job. For a mission critical environment, it seems like the better behavior would be: 1) keep the previous db 2) download the new db 3) if the new db is bad, throw an error in the logs/stdout, and keep functioning propperly on the old db 4) if the new db is good, move it over to the old db's location and start using it. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Why does clam die on a malformed database ?
Sander Holthaus wrote: A tempfail is not a disaster in most scenarios. You may not be able to receive mail until it is fixed, but you still get the mail after it is fixed. I think that attitude works fine in trivially small email environments. I don't think it works at all in environments where you've got an enterprise email system in a mission critical environment, where having an email delayed significantly can have financial implications. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Why does clam die on a malformed database ?
Sander Holthaus wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Rudd wrote: Sander Holthaus wrote: A tempfail is not a disaster in most scenarios. You may not be able to receive mail until it is fixed, but you still get the mail after it is fixed. I think that attitude works fine in trivially small email environments. I don't think it works at all in environments where you've got an enterprise email system in a mission critical environment, where having an email delayed significantly can have financial implications. A mission critial envirorement where having an email delayed significantly can have financial implications will not rely on one single virusscanner, but has two or three backups and never needs to throw a hard or tempfail when just clamav fails. And they are likely to employ much more scrutiny in using and updating non-standard db's. All of those things are true, but they're not a license for lax standards in how a process handles failures. We can handle error conditions poorly, because if it matters, they probably spent money on a second line of defense is bad coding discipline. There's no good reason for a process to die quietly because it's _new_ data is bad. That's a reason to not use the new data. It is not a reason to die (esp. not in a quiet manner). ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Why does clam die on a malformed database ?
Dave Warren wrote: In message [EMAIL PROTECTED] John Rudd [EMAIL PROTECTED] wrote: Sander Holthaus wrote: A tempfail is not a disaster in most scenarios. You may not be able to receive mail until it is fixed, but you still get the mail after it is fixed. I think that attitude works fine in trivially small email environments. I don't think it works at all in environments where you've got an enterprise email system in a mission critical environment, where having an email delayed significantly can have financial implications. If having an email delayed causes significant financial implications, you've got more serious underlying issues. SMTP is a best-effort process, there is absolutely no guarantee of delivery at all, let alone timely delivery. While I agree with you, the fact is I don't make policies. I can't _stop_ people from sending grants applications through email. I can't stop them from doing business transaction confirmations through email. And I can't force the top level management (most of whom are faculty who have done those two things in the past) to recognize the reality of what SMTP is, and was designed for. It's hard enough to just get them to accept that email is not an instant communication mechanism. (and, really, I wouldn't need to do virus scanning at all if I could get them to listen to technical realities, because they wouldn't be trying to use email as a file transfer mechanism, and I could block all of that traffic) ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Why does clam die on a malformed database ?
Sander Holthaus wrote: Dennis Peterson wrote: This is a very naive or at least uninformed position to take on the monetary significance of email. The issue is that email never was designed to be used in that particular fashion. No offense, but Dennis is right. You're being naive. The issue is not how it was designed to be used. The issue is how it is actually used. The latter carries FAR more weight, outside of purely academic discussions, than the former. Even though I work at a university, I do not live in an academic world. I live in the real world. And in the real world, email is used that way, and it is a mission critical service that has financial repercussions. Arguing about how it was designed to be used is just picking nits. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Freshclam stability as a daemon [was: DB Update email before actual update available?]
Per Jessen wrote: Dennis Peterson wrote: And as an old school Unix admin who still believes in the mentoring responsibility of my position, I will make recommendations from time to time regarding best practices and I recommend if you run freshclam as a daemon that you monitor it and restart it if needed. Do you do that for ALL your daemon processes? As an old school mainframe sysprog, I don't monitor any of my daemon processes. (apart from *some* status-monitoring via SNMP). Throwing my 2c in, I have a cron job that runs every couple hours and just reports on the status of various daemons. It tells me if any of them are missing, basically. But, it doesn't try to restart them (bad idea, IMO; for most daemons, it's better for a human to go look at why the process isn't running and try to solve it, instead of just blindly/programatically trying to restart it). It's just warning me that something that _should_ be running is not. In the 2 years I've been running clamav, I haven't had freshclam come up missing. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Clamscan on HP-UX
Fajar A. Nugraha wrote: Dennis Peterson wrote: Fajar A. Nugraha wrote: Database objects can include blobs (binary large objects). These can be files including executables, documents, other databases. They can have viruses. In some instances the blob in an internal representation and can be difficult to get to without sql. In other cases blobs can be external storage objects (file system files) and easy to get at. Regardless, there are many reasons one would wish to scan them for viruses. Yes, but (suppose) clamscan finds a virus on file oradata01.dbf. Would you REALLY spend your time examining which record on what table has the BLOB? Seems like that would be a bad method for scanning a database for infected BLOBs. A better mechanism might be to write a process which looks through the database (via the database's normal access mechanisms, and doing queries on the tables which contain blobs), and then submitting the individual blobs to a virus scanner (any virus scanner) for individual checking. What you do from there depends on individual goals, but the choices might include: a) sending a report to relevant parties about which records (by record ID, or whatever) contain infected blobs b) deleting the records which contain infected blobs c) replacing the infected blob with a disinfected version of said blob d) replacing the blob with a notice indicating that the the blob had been infected and removed, possibly placing the blob into a quarantine area (or deleting the blob). e) combine approaches: send a report that says which records were infected, place the original blob in a quarantine and replace it with either a notice or a disinfected blob (depending on whether or not the disinfection was possible/successful). ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Cherishing my ignorance - An appeal to package rs
James Kosin wrote: Like Dennis said Bringing it all together is what the admin is for. I disagree. There are some things which are the admin's job, but they are not the catch-all for all unresolved burdens (bringing it all together). Pardon my lecture, but lets review the root of our discipline: The purpose of computers is to shift the workload of as many tasks as possible away from the human and toward automation, freeing up the human to address more sophisticated problems they were previously unable to address due to those workloads. This is the mantra of the entirety of computing. If you are working with computers, and this isn't the focus of what you're doing, even indirectly, then you're not contributing to the domains of computer science and/or computer engineering. Period. No ifs ands nor buts. Even with games: the more sophisticated problem is having more complex/sophisticated environments for recreation. Notice that I did NOT say users, I said humans. This applies across the entire scope of computing, and not just at the level of what do we provide to the end user? For the hardware developer (whether it's chip developers or platform developers), their burden is to reduce the workload of everyone by increasing the overall capacity of the systems ... but more directly, they should also be reducing the workload of the system engineer. The system engineer has three groups whose workload they need to reduce: system administrators, application developers, and users. Application developers have two groups (depending upon the scope of the application): other application devleopers, system administrators, and users. System administrators have two groups they need to address: application developers and users. Users also have groups they need to address: themselves (if they're not going to leverage the tool to allow them to accomplish tasks that their previous drudgery was preventing them from addressing, then what's the point?), and non-computer users that are their customers (the bank teller who can not give you more information than they used to, because the information is all now at their finger tips ... before computers at the bank teller, they couldn't do that). ClamAV is an application. Its target audience is all three of the ones I mentioned for application developers. Therefore, the developers of ClamAV have the burden of reducing the workload of system administrators, users, and other application developers. The obvious manner in which they address this is making it easier to identify viruses so that the user or sysadmin can eliminate the virus from their environment, or so that other applications may leverage this identification process for automated deletion/interception of viruses. But, that is not the only manner in which application developers should reduce burdens (at the level of the problem being solved). They should also reduce other burdens where they can, such as reducing the ergonomic burden of the user (ie. better user interface design). And they should reduce the burden of the system administrator by making the application easier to maintain at the system administration level. That means doing things like using standard installation locations, using standard configuration tools, etc. It also means using easier and more reliable packaging and installation/removal mechanisms. Reduce the burden of the system administrator by making the installation task more streamlined, more reliable, and easier. So, to get back to the original quote: Bringing it all together is what the admin is for. No. You do not get to simply dump this burden upon the sysadmin. That burden is shared across the entire domain of computing. Each person is responsible for bringing it together for the community to which they are providing an automation. You might say but this subject is the responsibility, within 'Application Development' of the release engineer, and ClamAV doesn't have enough release engineering volunteers to address more sophisticated release engineering processes. OK, that's a reasonable response. But that's saying we don't have enough resources to address one of our burdens. That means the request was valid, but we can't address it. That is ENTIRELY different from a response of the request is unreasonable/invalid because our consumer should just be willing to do more work (effectively what the OP's detractors have been saying). BZZT. That response directly contradicts the central purpose of computing. Therefore, that response is inherently wrong and inappropriate. ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Cherishing my ignorance - An appeal to package rs
tBB wrote: I'm sorry for the probably arrogant and insulting tone but you're literally asking for it. Perhaps he is asking for it, but he's also right. ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Cherishing my ignorance - An appeal to package rs
Dennis Peterson wrote: My not-so-automated update process looks like this: wget (link to current clamav-XXX.tar.gz) tar xzf clamav-XXX.tar.gz cd clamav-XXX configure --disable-zlib-vcheck make su make install service clamav restart service freshclam restart You would be wise to uninstall the previous installation so that you don't end up with split versions. The man pages have not always been consistent nor have library names, and uninstall (make uninstall) helps prevent this. It would be nice, though, if there was a clamav-current.tar.gz to download, so that such automated processes could be done more ... automated. ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Cherishing my ignorance - An appeal to package rs
Dennis Peterson wrote: Bowie, The obvious observation that while this might work for you it's not a general solution, so now everyone needs to create a script. F'chrissake... It is trivial to do this. Less than 10 minutes, start to stop. I wrote the script I use 3 years and it took just minutes. I have 10 mail servers in 5 timezones and three continents. They are all updated within 30 minutes of a new drop. This is not rocket science - in fact this is very simple stuff. If you are challenged by *any* of this you are in the wrong business. Care to share your script? (and, hopefully its written in a fashion that is portable, instead of being linux specific ... or worse yet, specific to a given linux distro) ___ http://lurker.clamav.net/list/clamav-users.html
