Re: [Clamav-users] Re: Clam Packet Scanning
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. raj ___ 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
Re: [Clamav-users] Re: Clam Packet Scanning
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? 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. raj ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Clam Packet Scanning
On Monday 30 January 2006 02:10, Rajkumar S wrote: 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. well, some p2p apps keep checksums of their parts so they know the file went across ok, so they'd see the zero'd out parts, the checksum would fail, and they would try again, see the zero'd out parts, checksum would fail, try again, checksum fail, try again I would say just ban the use of p2p apps like kazaa, limewire on your network, and police it very closely. Anyone who doesn't follow the rules gets the door. -Jeremy -- Jeremy Kitchen ++ [EMAIL PROTECTED] In the beginning was The Word and The Word was Content-type: text/plain -- The Word of Bob. pgpZbucfv0lnf.pgp Description: PGP signature ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Clam Packet Scanning
On 1/30/06, Rajkumar S [EMAIL PROTECTED] wrote: 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. What about out of order packets? What about duplicates...? The short answer is, no such approach, even if you can get it performing reasonably well, will be completely effective. You would be better off defaulting to blocking all outbound traffic and routing all allowed traffic through proxies or gateways. Keep in mind that clamav can't catch a virus it doesn't have a signature for. For there to be a signature somebody has to have reported it. That means that it has to be in the wild *before* you can get signatures to detect it. Which may mean that you're already infected. This isn't unique to clamav. -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche ___ 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
Re: [Clamav-users] Re: Clam Packet Scanning
Rob MacGregor wrote: On 1/30/06, Rajkumar S [EMAIL PROTECTED] wrote: 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. What about out of order packets? What about duplicates...? These are problems, I was actually looking at this from a theoretical perspective, like can this approach ever work. Our of order and duplicate packets are solvable problems (I understand they are not easy, but IDS has done it before) So is performance. be better off defaulting to blocking all outbound traffic and routing all allowed traffic through proxies or gateways. It may not be possible to run proxies for all applications used by users. While proxies are one of the better ways to control traffic, I am just exploring alternate ways to achieve a much more general solution. That means that it has to be in the wild *before* you can get signatures to detect it. Okay. Which may mean that you're already infected. How come? A virus in wild I getting infected. But there is a chance that wild == my PC :) But that's the risk we take with all AV. raj ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Clam Packet Scanning
Mar Matthias Darin wrote: Hello, Rajkumar S writes: 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. That's a nice number. I am pretty encouraged by this possibility. Time to go coding :) raj ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Clam Packet Scanning
Rob MacGregor wrote: On 1/30/06, Rajkumar S [EMAIL PROTECTED] wrote: 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. What about out of order packets? What about duplicates...? What about tar files? What about zip files? dp ___ 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
Re: [Clamav-users] Re: Clam Packet Scanning
On 1/29/06, Mar Matthias Darin [EMAIL PROTECTED] wrote: 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. At the proxy level it should work reasonably well (keeping in mind that clamav is aimed at catching email viruses). I've used products that work that way before. As a packet scanner I'd be surprised if it ever amounted to much. The technical problems are rather large :) Off the top of my head: 1) You'd need to decode the packet contents on the fly 2) Anything running over 1 packet would never be spotted 3) By the time the packet has gone by, it's probably already too late 4) If you run inline the delays will be significant 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. Ultimately that's a business decision, not a technical one. -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Re: Clam Packet Scanning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mar Matthias Darin wrote: 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. Look at http://clamav.net/3rdparty.html#other What you describe is similar to Endian Firewall, Snort-ClamAV, Snort-inline and perhaps RedWall Firewall. - -- René Berber -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iEYEARECAAYFAkPcBU4ACgkQL3NNweKTRgwPXACg/FJu753iMaTYevrMWslTivPs A+MAoKCgfTV7VaUqp0xnzttMkNdYonKr =F9Fk -END PGP SIGNATURE- ___ http://lurker.clamav.net/list/clamav-users.html
