Re: [Clamav-users] [OT] Rbl listing
Hello, Matt Fretwell writes: Good job I was just testing this rbl with a warn status on the mailserver :) I 've found using a warn for RBLs to be the best approach. As to the unofficial sigs I'm hold off until more testings is done. I have to question the integrity of using them in a virus scanner virsus a spam scanner... I am open to further evaluation on this though... pgp9BuUR4wjvN.pgp Description: PGP signature ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Re: Clam Packet Scanning
Hello, Rajkumar S writes: Mar Matthias Darin wrote: I have done some research on this already... If you store the file in a disk buffer (say max 100K at a shot using tmpfs for speed), then scan the buffer, it does indeed work. How short can this buffer go? Does this file needs to be seekable? Ideally, I would say 16K would be as small as you want to go. If the buffer is to small, the transfer speed will suffer. Where your problem is going to occur, as with havp, is in notifing the user that their file was trashed unless the P2P software incorporates the antivirus scanning inline with the downloading. In such a manner, the P2P can notify the user that the transfer was abort and why. One way would be to overwrite the matched signatures with zero, that would defang the file. Another way would be to use this in conjunction with desktop virus scanner where the gateway antivirus would provide "defence in depth", There is no fit all approach here. These would work. However; one must take into account that many end-users would not have an understanding of this technique when their computer locks up from a bad jump table in the EXE header. My personal opinion is that the antivirus at this level needs to be integrated into the application or have hooks that allow easy integration. pgpVDFNWYdZof.pgp Description: PGP signature ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Re: Clam Packet Scanning
Hello, Rajkumar S writes: Rob MacGregor wrote: 1) You'd need to decode the packet contents on the fly 2) Anything running over 1 packet would never be spotted Just wondering how far a signature can go? Does the scanner needs to go back and forth in a file for scanning or can it scan a stream as it passes by? How far does it needs to go if it has to go backwards? What about zip files? Do they need to be unzipped before scanning ? The idea is to have a small packet queue where last n packets are stored, scanned and then transmitted in a cyclic fashion. ie first n-1 packets will just gets queued, when the nth packet arrives, the queue is scanned, and 1st packet is released and nth packets is appended to the queue. This process is repeated for every packet. Now don't flame me about performance, I just want to know if such an arrangement will catch all virus in that stream or if some virus will get past this. What I just looking if such a thing is ever possible (as opposed to feasible) The aim is to catch malware that comes via a random tcp connection, like some sort of p2p application. I have done some research on this already... If you store the file in a disk buffer (say max 100K at a shot using tmpfs for speed), then scan the buffer, it does indeed work. HAVP uses this technique quite well. Where your problem is going to occur, as with havp, is in notifing the user that their file was trashed unless the P2P software incorporates the antivirus scanning inline with the downloading. In such a manner, the P2P can notify the user that the transfer was abort and why. pgpyxSSbUCk3c.pgp Description: PGP signature ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Re: Clam Packet Scanning
Hello, Look at http://clamav.net/3rdparty.html#other What you describe is similar to Endian Firewall, Snort-ClamAV, Snort-inline and perhaps RedWall Firewall. I have looked at them and their source code before. These do not answer the questions of feasibility and practicality of a packet level virus scanner. My interest is not weather it can be done... but rather weather the time and technical merit in doing so will produce an acceptable catch catch percentile. If this methodology catches 80% of viruses, then it is indeed worth the investment, if it catches only 20%, is the approach still worth the time and resources to develop, refine, and maintain it. A good example of this is the U.S. gov't spend $8 million a year to study cow burps and $13 million to research fly farts WHY? Where is the practicality of this and to what ends will this "research" be used other then simply to waste money? It is this line of thinking that I am interested in, is virus scanning single packets worth the cost of production. Not weather it can be done or rude and inconsiderate comments from individuals that obviously missed the intent of the question. Thank you in advance. pgphkFr1lblS0.pgp Description: PGP signature ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Clam Packet Scanning
Hello, I realize this is probably a redicules question, but what is the feasibility or praticality of catching viruses through a packet scanner (firewall or IDS) solely at the packet level? For example (poor one but does illustrate the concept): tcpdump -n -l -X | clamscan - I can think of a few shortcommings: 1. a virus will be missed if the signature splits packets. 2 no realistic way of notifing the end user that a packet was infected and destroyed, hence was their download. Thank you in advance. pgpbZWBPZEd6T.pgp Description: PGP signature ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Re: kernel: Out of Memory:Killed process xxxxx
Fajar A. Nugraha writes: Okay, now suppose that clamd works in a "complicated" way, so that "The effect is that you don't *always* get back what you free() when you free()", Do you have any suggestion as to how to get back the free()d memory? Will (borrowing Apache's way) using a prefork-kind of daemon, with limited lifetime for each child, be better (in sense of memory management) than the current thread implementation? Or perhaps limiting the lifetime of each thread sufficient? From experience with pthreads and Linux v2.4, pthreads was a royal pain. I initially used threads as a method of a limited lifetime model for my firewall design... I kept getting unusual and unpredictable segfaults. The process would run anywhere from 2 days to several months, then for no appearent reason,segfault in a routine that had been tested a thousand times under high stress conditions and not failed. I confirmed that pthreads leaks memory in the management thread when calls were made to usleep. (nanosleep -> _nanosleep). GDB brought up the error after to weeks of running the process in a debug state. After moving to fork() and named pipes, the same code hasn't broken once in nearly a year of hard testing. My tested often included 10 or more icmp floods of at least 65535 packets. I drove my load to 240 during the test... Now the forked process uses and frees memory thousands of time per second with no issue... Pthreads work well for light duty non-daemon processes... If its heavy duty pgp0P22yNpEzZ.pgp Description: PGP signature
[Clamav-users] Re: OverSize.Zip file
Laura Penhallow writes: I apologize in advance if this is something easy, but I am at my wits end. We have a customer that needs to receive rather large zip files from a client of theirs. Trouble is -- clam keeps classifying the attachment as an OverSized.Zip virus and rejects it. The zip file is ~8.7 mb contains 1506 files and winzip reports 78 % compression. We're running Clam v 0.74 I have been googling and reading other posts and I have made the following changes to clamav.conf Are you using clamdscan or clamscan? I had similar problems when I was setting up my antiviral engines for exim. I found that I often got different results between the two. Clamdscan would bark on the file, while clamscan would not complain. pgp3JGn2Wf5Sk.pgp Description: PGP signature
[Clamav-users] Re: Compression limit ..... Much too low for me :(
Have you considered auto-converting the .bmp to a .jpg, and remiming the message? Also, stripping the image and putting it into a temporary web link(expires and deletes say after 12 hours)? Both might be options to use on your users I have many similar things I've had to do to keep security high and resources low. Lionel Bouton writes: Jason Haar wrote the following on 08/29/2004 11:26 AM : On Wed, Aug 25, 2004 at 07:42:24AM -0400, Jim Maul wrote: webmasters using BMPs?? I'd leave it at 200, tell him to use jpgs or pngs and That's a very rough response... I mean - I agree with you - but people will be people. I personally think that compression option should be classified the same way as the "encrypted zip file" option: disabled by default, and should have more of a description as to why and how you should set it. Disabling it would probably cause problems on high traffic mail servers if mail bombs come their way... You need disk space to decompress these files and CPU time to decompress and scan. I disabled it as we had too many people who seem to be sending large BMP files around: instead of the naive, non-IT end-user trying to find some TOOL to convert their BMP to a JPG, they did the next smart thing and put it into a ZIP file - thus getting the great compression they were after before e-mailing it off. (I haven't had time to figure out what ratio would be high enough to allow all such files in, so have disabled instead of setting it higher - which I would actually prefer) To blame users for such an action is a bit extreme... Not everyone is a Linux user or a Windows programmer/designer - like we are ;-) No, but if you tell them BMP is bad (with some explanations like : they reduce the network performance, can be blocked by the destination mail server anyway, need more powerfull computers to process -> money not going into their salary in the end...), block high ratio zips and make sure they all have the software to make GIF/PNG and have a web page on a "knowledge base" web server showing how to save the files in these formats with some screen caps, they will learn. If you don't educate your users you'll end up with more and more problems to solve (regular virus cleaning, server load going through the roof, having to pay for big pipes and expensive servers to cope with their monstruous files and belief that SMTP is a file distribution protocol, ...). Regards, pgpNodsK6Cs7E.pgp Description: PGP signature
[Clamav-users] Re: dev virus database
I had nothing but headaches with uvscan... We run 4 virus scanners and 4 other tests to a one-stop-server (all services)... Our load is pretty good, usually below 1.00. We process approximately 20,000 messages a day. I found that running clamscan rather then the deamon was a better option. I noticed the deamon was a little heavier in resources. What mta are you rinnung? That was my biggest bottleneck... Nigel Horne writes: On Sunday 29 Aug 2004 20:35, Graham Toal wrote: > Update to 0.75.1 or CVS. If we ever get overloaded however I would turn clamav off first, as it is much more of a CPU hog than uvscan] You should find the CVS version is better than 0.75.1 in this respect. -Nigel pgp2CEsiQNwsB.pgp Description: PGP signature
