You can configure scheduled scans of your system with clamav. As for real time protection, that'll take some research - might even have to consider a commercial product. But if you end up paying for a commercial product, you might as well get one that also supports ICAP - the popular ones do nowadays, but it's best to confirm.
~Sent from my Google Nexus 6P~ On Mar 10, 2016 1:06 AM, "Rubén Toribio Aldeguer" <rtori...@riu.com> wrote: > Thanks, This information is very ussefull for me too. What about for an > antivirus on the server? do yo have any experiencie with it? > > TX. > > 2016-03-09 21:22 GMT+01:00 Wei-min Lee <weimin.b....@gmail.com>: > >> Using ICAP is a good way to go so that the person uploading files can be >> notified of upload fails due to the virus scan. Relying on filesystem >> virus scans lacks visibility of quarantined/rejected files. >> >> On Wed, Mar 9, 2016 at 12:18 PM, Wei-min Lee <weimin.b....@gmail.com> >> wrote: >> >>> You could use clamav via ICAP with squid transparently in front of >>> apache. >>> >>> http://wiki.squid-cache.org/ConfigExamples/ContentAdaptation/C-ICAP >>> http://squidclamav.darold.net/config.html >>> >>> http://louwrentius.com/setting-up-a-squid-proxy-with-clamav-anti-virus-using-c-icap.html >>> >>> On Wed, Mar 9, 2016 at 8:12 AM, Aurélien Terrestris < >>> aterrest...@gmail.com> wrote: >>> >>>> On a large scale prod (200 000 users/day), I was using proxies working >>>> with antivirus through ICAP protocol (RFC 3507). The results were pretty >>>> good. >>>> I am not sure we could use this technology with Apache, and ICAP seems >>>> a bit old now. >>>> >>>> 2016-03-09 16:45 GMT+01:00 Christopher Schultz < >>>> ch...@christopherschultz.net>: >>>> >>>>> John, >>>>> >>>>> On 3/9/16 10:21 AM, Rose, John B wrote: >>>>> > What about if your web sites allow for uploading files? Would you >>>>> not want >>>>> > to scan those on upload before they got on your filesystem? >>>>> >>>>> Sure, it would be nice to have the file scanned during upload, but I'm >>>>> guessing that the AV can't give an opinion on a file until it's been >>>>> completely-uploaded. In that case, do you really want to buffer the >>>>> whole file in memory to scan it? >>>>> >>>>> I think the file is going to make it -- at least in part -- to the disk >>>>> either way, unless you have other controls in place such as upload-size >>>>> limits where you can make a good bet that in-memory scanning can be >>>>> done >>>>> without bringing-down your server. >>>>> >>>>> Anyhow, I don't have any particular experience with mod_clamav or >>>>> anything like that. Certainly I wouldn't rely upon it solely, since >>>>> there are other ways files can make it onto your server(s). But it >>>>> probably couldn't hurt. >>>>> >>>>> Things I'd be worried about are which requests will be scanned by the >>>>> AV? Will every single GET/POST/etc. be scanned? That might cause a >>>>> significant impact on your response times. Also, the aforementioned >>>>> buffering -- does the file have to remain in memory to be scanned, or >>>>> will it be streamed to a disk somewhere first? You don't want AV-scans >>>>> to bust your memory cap. >>>>> >>>>> -chris >>>>> >>>>> > On 3/9/16 9:49 AM, "Christopher Schultz" < >>>>> ch...@christopherschultz.net> >>>>> > wrote: >>>>> > >>>>> >> John, >>>>> >> >>>>> >> On 3/8/16 6:02 PM, Rose, John B wrote: >>>>> >>> I am interested in both >>>>> >>> >>>>> >>> Thanks >>>>> >>> >>>>> >>> Sent from my iPad >>>>> >>> >>>>> >>>> On Mar 8, 2016, at 3:27 PM, Christopher Schultz >>>>> >>>> <ch...@christopherschultz.net> wrote: >>>>> >>>> >>>>> >>> John >>>>> >>> >>>>> >>>>>> On 3/8/16 2:43 PM, Rose, John B wrote: >>>>> >>>>>> Looking for comments on mod_clamav, and any other alternative >>>>> >>>>>> antivirus software for Apache on linux >>>>> >>> >>>>> >>> Are you trying to protect your clients or your servers? >>>>> >> >>>>> >> I would imagine that running any AV software that monitors the >>>>> >> filesystem for changes would be sufficient. Why do you think you >>>>> need an >>>>> >> httpd module for this? >>>>> >> >>>>> >> -chris >>>>> >> >>>>> >> >>>>> --------------------------------------------------------------------- >>>>> >> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org >>>>> >> For additional commands, e-mail: users-h...@httpd.apache.org >>>>> >> >>>>> > >>>>> > >>>>> > --------------------------------------------------------------------- >>>>> > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org >>>>> > For additional commands, e-mail: users-h...@httpd.apache.org >>>>> > >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org >>>>> For additional commands, e-mail: users-h...@httpd.apache.org >>>>> >>>>> >>>> >>> >>> >>> -- >>> *~Wei-min Lee~* >>> >> >> >> >> -- >> *~Wei-min Lee~* >> > > > > -- > > *Rubén Toribio Aldeguer* > Técnico Sistemas DataCenter > Informática Área Sistemas > (+34) 971743030 > www.riu.com / www.riuplaza.com > > > [image: Facebook] <http://www.facebook.com/Riuhoteles> [image: Twitter] > <http://twitter.com/#%21/RiuHoteles> [image: Flickr] > <http://www.flickr.com/photos/riuhotels/collections/> [image: Youtube] > <http://www.youtube.com/user/RiuHotelsandResorts> [image: Google Plus] > <https://plus.google.com/102337793674910512804/posts> > > > > This e-mail and its attachments, if any, are confidential and may be > legally privileged. If you have received it in error, you are on notice of > this status. Please do not copy or use it for any other purpose or disclose > its contents to any other person: to do so could be a breach of confidence. > You may contact us at +34 971 74 30 30 or at sender's e-mail address. > [image: Facebook] *Please, consider the environment before printing this > email.* <http://www.riu.com/es/sostenibilidad/inicio.jsp> >
