> It's only a question of time that AV-engines will run a virtual PC > sandbox and let start inside the suspicious file. If certain actions > are taken like outgoing smtp-connections, registry-changes, changes > in the %windir% directory structure it's very suspicous.
Not sure that I agree that the in-line scanning sandbox is so feasible. It's been spoken of in various forms for about a decade now, but hasn't reached the mainstream. I think the real-world feasibility problem is understandable, when, for example, you're talking about files like MSIs, installer EXEs, etc. Outgoing connections, registry changes, and system area changes are not only not suspicious with legit files of these types, they actually define their _normal_ behavior. Certainly, the big virus response centers run things through sandboxes over longish periods of time to catch their signatures. But letting something run for a day as a simulation is not going to fly for mail scanning, y'know? > First of all in my opinion it should be replicable across multiple > servers in order to avoid failures due to overload and DDOS-attacks. That would certainly be the case with any DNS-based database, but. . . > Adding additional file properties like file size and CRC checksums > is a good idea. Who has the knowledge to set up such a > DNS-structure? . . . rather than starting from scratch, I'd first look closely at the development of prior concepts like Pyzor, Razor, and DCC. None of these well-accepted distributed-digest networks use straight DNS, though I'm not exactly sure of the reason(s). One may be the extended "write" command set that they support for message submission, which might be easier to implement using DNS now than it was in the past, since DDNS is in wide use. Another reason is likely the need for a security wrapper. And another reason is the maximum request size they support. Then again, your idea -- and I like it a lot -- may not require a read/write protocol, and may be totally public. If only used for public lookups, DNS may prove to be usable. I think we should also think about extending SMTP as a transport as well, since it's more flexible and has an existing command set that's easy to use for pass/fail/tempfail + verbose result string. Of course, seeding the server side of an SMTP-based solution would be significantly different from seeding a DNS-based solution. Doesn't have to be too hard, though. . . you can use an envelope (streaming) content filter (as offered by many MTAs, though not by IMail) to serve this up to the world, setting up the message digests as if they were keywords. Full disclosure: I'm already doing this for various experimental purposes, and am excited by it. True, though, it does not natively support a replication protocol. > Who can develope an external test who is able to extract all > attached file names (full Mime-type support needed or based on the > temporary directory created by declude.virus? My feeling is that using Virus' built-in MIME decoding is a better move, since it's been tuned for irregular encodings for quite a while. If you discover bugs in it (like Matt has), the fact that you're truly relying on it for virus protection should help get them fixed, whereas if you use a third-party library (let alone trying to build and test your own library), you can't make feature requests directly to Declude. I think anything that doesn't satisfy in Virus (EVA) should be brought immediately to the developer. > Should it be an external test for d.junkmail in order to have much > more possibilities or should it act like an av-scan engine with > simple result codes and a report-file that is able to give the > feedback as virusname like "file ... is a possible virus" While I would admit that building as a Junkmail test would be more flexible, I think that duplicating Virus' MIME work is a bad move. Better that we continue pressure to get Junkmail full MIME capability, which has been a long time coming. Eventually, I'd hope that the two products merge, like all the other framework/aggregator products out there (I don't know of any other mail security products that attempt to segregate the "types" of external executables you can shell to. . . it doesn't really make a lot of sense). --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] ------------------------------------ --- This E-mail came from the Declude.Virus mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.Virus". The archives can be found at http://www.mail-archive.com.
