Re: better techniques to identify and remove zero-day viruses from cyrus store sought
Jorey Bump wrote, On 8/22/2007 8:23 AM: > John Crawford wrote: > >> Sieve is during delivery to the cyrus store though. >> As we have the capability to identify hazards to our >> users, I'd like to be able to exercise central >> strategies improve their quality of life. So I seek >> tools to leverage after detection to aid with >> removal or remediation. >> >> Maybe would be nice to have a just-in-time scan interface >> at the cyrus message level just as a message is being >> accessed. CPU processing is getting cheaper all the time. > > Hmm, this is an interesting problem. At one extreme, you're changing the > mailstore or connection while the user is logged in, which could > result in some confusion (and possibly trigger some client software > issues). At the other extreme, you may have an account that hasn't been > checked for weeks, so it's fine to remove malicious messages that have > accumulated due to lack of detection before delivery. You also have to > be careful not to remove messages that have been forwarded to your > support address, as they will contain strings that may trigger detection. > > To handle all cases safely, you'd probably want to script using > Cyrus::IMAP::Shell, so all changes are performed via IMAP. You can do > this safely with Cyrus because it supports concurrent R/W access. > Instead of deleting these messages, you'll want to put them in a > quarantine account so you can restore them in the case of false positives. I don't see that it's possible to read any particular message, or to iterate and evaluate content of messages with Cyrus::IMAP::Shell. Do I miss something? > > I'm still not sure I'd be comfortable doing this beneath the nose of a > logged in user. I'd also hesitate to touch anything outside the INBOX > (and any quarantine folders you provide), since it can be assumed that > the message was moved due to user action. I'd probably test this for a > long time only on accounts that aren't being checked regularly (this > also has the benefit of reducing the size of abandoned accounts). > > Have you found that the risks justify this effort? Are your ClamAV scans > of the mailstore turning up anything? Are they serious threats? Yes, I get very good results of content I would like to safely hide away. I use standard clamav with the usual clamav signatures. I've not experienced problems from any false positives. I'll have a signature update, and it will find messages received 50 minutes earlier - ones my users don't need to be exposed to. thanks, John > > > Cyrus Home Page: http://cyrusimap.web.cmu.edu/ > Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki > List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html > Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: better techniques to identify and remove zero-day viruses from cyrus store sought
Jorey Bump wrote: > Have you found that the risks justify this effort? Are your ClamAV scans > of the mailstore turning up anything? Are they serious threats? I've just scanned a mailstore with ClamAV, and about 95% of the 'FOUND' infected files were false positives. Here there be dragons. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: better techniques to identify and remove zero-day viruses from cyrus store sought
John Crawford wrote: > Sieve is during delivery to the cyrus store though. > As we have the capability to identify hazards to our > users, I'd like to be able to exercise central > strategies improve their quality of life. So I seek > tools to leverage after detection to aid with > removal or remediation. > > Maybe would be nice to have a just-in-time scan interface > at the cyrus message level just as a message is being > accessed. CPU processing is getting cheaper all the time. Hmm, this is an interesting problem. At one extreme, you're changing the mailstore or connection while the user is logged in, which could result in some confusion (and possibly trigger some client software issues). At the other extreme, you may have an account that hasn't been checked for weeks, so it's fine to remove malicious messages that have accumulated due to lack of detection before delivery. You also have to be careful not to remove messages that have been forwarded to your support address, as they will contain strings that may trigger detection. To handle all cases safely, you'd probably want to script using Cyrus::IMAP::Shell, so all changes are performed via IMAP. You can do this safely with Cyrus because it supports concurrent R/W access. Instead of deleting these messages, you'll want to put them in a quarantine account so you can restore them in the case of false positives. I'm still not sure I'd be comfortable doing this beneath the nose of a logged in user. I'd also hesitate to touch anything outside the INBOX (and any quarantine folders you provide), since it can be assumed that the message was moved due to user action. I'd probably test this for a long time only on accounts that aren't being checked regularly (this also has the benefit of reducing the size of abandoned accounts). Have you found that the risks justify this effort? Are your ClamAV scans of the mailstore turning up anything? Are they serious threats? Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: better techniques to identify and remove zero-day viruses from cyrus store sought
Jorey Bump wrote, On 8/21/2007 2:28 PM: > John Crawford wrote: > >> What's the best way, and second best way to react to zero-day virus >> threats - messages that are delivered to the mail store before the >> detection is in place? > > Any detection that can take place in the mail store can (and should) be > moved up the chain, preferably to the MTA. Thanks to Jorey and Joseph for the replies. The MTA- that is where the scan occurs for inbound mail. Once it's arrived, it's can be re-evaluated with the benefit of newly incorporated methods of detection. Some of our techniques are effective against attachments and identifying known mail content hazards. And of course this is a layer before the Mail User Agent handling, which may also have detection capabilities. (depending on the user and their client). We do have blocking for hazardous attachments, etc. Clamav has been a nice tool for locating phishing messages and "please visit my website to see if I can hack in" ecards. The MUA side detection most clients have is less effective against these though. > >> Is there a best practice that functions nicely >> within the cyrus community? > > Yes, once a message is delivered, leave it alone. The most you should do > at that point is maybe provide an opt-in sieve rule that stores > suspicious messages in a special folder. But even this has caveats, and > I prefer to let the users sort their own mail. > Sieve is during delivery to the cyrus store though. As we have the capability to identify hazards to our users, I'd like to be able to exercise central strategies improve their quality of life. So I seek tools to leverage after detection to aid with removal or remediation. Maybe would be nice to have a just-in-time scan interface at the cyrus message level just as a message is being accessed. CPU processing is getting cheaper all the time. thanks, John > > > > > > Cyrus Home Page: http://cyrusimap.web.cmu.edu/ > Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki > List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html > Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: better techniques to identify and remove zero-day viruses from cyrus store sought
John Crawford wrote: > What's the best way, and second best way to react to zero-day virus > threats - messages that are delivered to the mail store before the > detection is in place? Any detection that can take place in the mail store can (and should) be moved up the chain, preferably to the MTA. > Is there a best practice that functions nicely > within the cyrus community? Yes, once a message is delivered, leave it alone. The most you should do at that point is maybe provide an opt-in sieve rule that stores suspicious messages in a special folder. But even this has caveats, and I prefer to let the users sort their own mail. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: better techniques to identify and remove zero-day viruses from cyrus store sought
John Crawford <[EMAIL PROTECTED]> wrote: > What's the best way, and second best way to react to zero-day virus > threats - messages that are delivered to the mail store before the > detection is in place? Refuse mail with executable attachments. List is at: http://support.microsoft.com/kb/262631 http://support.microsoft.com/kb/829982 This 100% effective and there are no zero-day or zero-hour problems. Done here since February 2003. Joseph Brennan Lead Email Systems Engineer Columbia University Information Technology Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
better techniques to identify and remove zero-day viruses from cyrus store sought
Hello. What's the best way, and second best way to react to zero-day virus threats - messages that are delivered to the mail store before the detection is in place? Is there a best practice that functions nicely within the cyrus community? Like a perl script that traverses the mail store (via imap or cyrus utilities) and checks message content against a antivirus command line? And then safely within the cyrus system deletes the message? I can't do that. I don't have that functionality. Can anyone share code or ideas to help make this happen? The second best I can think of is traverse and locate the storage system from the command line, remove found exploited messages and recontruct ASAP the mailboxes with changes. Here we are working outside of cyrus, so it's discouraged. long line: find /var/spool/imap/user/ -name "*\." -ctime -6h -print0 | xargs -0 clamscan | grep FOUND > badones remove and reconstruct based on file badones. As a related question, if I locate a message in the mail store from command mode, and neuter some aspect of the vulnerability presented by modifying the text of the stored message yet retaining the same message size, are then internal cyrus structures that require updating? I seem to get good results from this, but I'm guessing reconstruct afterwards is best. (and that the idea of modification from the file system is, yes, discouraged). thanks for any thoughts or ideas, John Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
