David Wilson wrote:
On Wed, 2009-01-14 at 11:07 -0500, Chris Lewis wrote:
.
Our experience, issuing 55x at levels of 250,000-1,300,000 per day since
1997 indicates exactly the reverse.
Certainly, there's no way to prove that "it" (an infection) hasn't
happened, but considering we've had precisely _one_ report of a 55x (for
any reason whatsoever) landing in the forgee's mailbox in all that time,
it can't be significant. In contrast to the dozen or so FPs per day
that we do handle. Silently dropping emails would mean that those dozen
or so FPs would go unnoticed by anyone.
Interesting. At least there are some numbers here.
Just to check, are these 250K-1300K 5xx response *just* for messages
which have fallen foul of Anti-Virus checks (i.e. the number does not
include 5xx responses for other causes like invalid recipients).
It's all filter hits, including spam, but not invalid recipients (we
don't, but should, count these at present - at least in production. On
the traps invalid recipient is 20-30M/day by definition ;-).
That said:
1) That 1.3M/day was virus rejects - the Mydoom explosion in Feb 2006
(IIR the year correctly). The total rejects for those days was actually
1.6M/day (I rechecked the numbers - was remembering Mydoom's numbers
alone for the total).
2) The FN rate of AV tools these days is atrociously bad. Studies have
shown that "new" viruses (in this context meaning different MD5
checksums, meaning the same old virus just packed differently) is missed
by 90% of all AV packages, and that only rises to 50% after a month.
In fact, some AV vendors are not bothering to update MD5 databases for
certain viruses, because they're different for every copy. That's not
supposition, at least one vendor explicitly said so. In person ;-)
I can't tell you how many times I've submitted a cutwail binary to
virustotal and found that not one of virustotal's battery of detectors
(commercial AV products) fired on it. Despite cutwail being (a) the 2nd
or 3rd most prolific malcious email sender (peaked at over 20% of all
malicious email), and (b) out there for better than a year.
As a consequence of (2), any non-trivial environment who relies purely
on AV products (even multi-layer such as us, with email and web and
generalized) for virus protection is going to get hosed. They have to
add in different approaches, such as DNSBL, SURBL, custom patterning and
executable detection. With _both_ a higher FP rate, and the inability
to tell whether it's a virus or not. You can't choose to "bounce (or
reject) spam and not viruses" because the filter is unable to make the
distinction. We used to publish "virus rejects" - we don't anymore,
because we can't distinguish them.
We have an internal formal AV engine in email. But we don't rely on it
for the heavy lifting of the majority of malicious attacks. The front
ends use anti-spam techniques, and catch better than 99% of it before
the AV sees (and probably misses) it.
As Alessandro Vesely has commented, this does seem a high AV FP rate.
The dozen or two FPs is are all a result of rejects, regardless of
actual rule (virus, spam or otherwise)
How do you find out about the FP (since the message is, by definition,
rejected)? Obviously, if the sender simply resends, it would be rejected
again. So, there must be some other mechanism you have for finding out
that this particular message was not actually infected.\
The rejection message (see previously in this thread for a real example)
states very clearly what the sender should do. Email the FP handler.
Which is my responsibility. So I see them all.
What kinds of message typically generate FPs? What AV signatures are
being hit by these FPs? How do you verify that the message is not
actually a problem?
Executables that aren't viruses. Ordinary email coming from infected
machines, or in amongst large numbers of badly infested machines. Very
badly configured machines. Etc.
We treat the FP process as simply part of filtering. If you get a
reject, report it, and we'll fix. No email lost. Merely delayed.
Maybe we are lucky, but we do not see many messages which appear to be
infected - perhaps only 0.6% of the overall traffic. Nearly 90% of
received messages appear to be spam. Do you get a significantly higher
proportion of (purported) infected messages?
I think you have an overly narrow definition of viruses - specifically,
emails that carry malicious executables _directly_. The trap
demonstrates that, at times, you'll see up to 50% of its entire flow is
viral in the sense of, for example, links to malicious files.
Most AV products probably didn't fire on the MSNBC/CNN viral attack.
Yet, at one point a few months ago, that alone was 25% of all trap
traffic. That was concurrent with several other bot families expending
a considerable fraction of their output trying to propagate instead of
sending spam.
Although the number of reported infections from rejected messages is
just one, maybe this is not surprising. Firstly, there are clearly "out
there" a very large number of machines which are infected and the owner
either does not know or does not care. So, if any of these have been
infected as a result of one of your rejections, you would not know.
We'd get reports of us being responsible for sending a virus if _only_
from us being mentioned in the rejection notice buried in the email.
Given the sheer volume of people who can't read headers well enough to
identify obviously forged received lines and report the spam to us
because it has a 47/8 address in it, we'd get at least _some_ reports of
us (apparently) bouncing viruses at one point in the past 11 years.
We NEVER have. The only rejection notice of this type we've ever had
drawn to our attention is when an infected ISP customer sent us a spam
forged in another customer of that same ISP, and our rejection caused
the ISP to send the reject back to the forgee.
Only once in 11 years. At our volumes, even if off by several orders of
magnitude, the risk of reject-induced-bounce-of-virus is insignificant.
Even more insignificant when you factor in the cost of missing business
email because you blackholed it because of a filter FP.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg