I switched off banning Ezip's since a very irate customer needs them. But I still had a Bagle slip through, I have updated my rule file many times since this email. Is there something else I need to do to stop Bagle?
Our rule wasn't intended to capture the versions of Bagle that actually have an attachment... only those that exploit the object-data exploit as referenced in the link below.
Message Sniffer is not really an anti-virus product, but we do our best to put in rules that help out with worms if we can. This helps to cover the "fringes" where true anti-virus scanners might not be able to act, or where a particular scanner might be slow to update.
You probably need to find a way to block ezips for everybody but this customer (I know that's not easy). In the mean time we have been adding rules for some variants that do contain zips and passwords... However the permutations represent quite a large number and we don't want to introduce false positives by making rules too broad.
Please consider the added anti-worm rules in Sniffer as an added layer of protection - and a very thin one at that.
Best,
_M
<snip - reference below>
We have just added a rule for the Bagle.Q worm derived from data at the following link:
http://www.auscert.org.au/render.html?it=3957
The rule should be present in your next update. A full rule-base compile is under way.
Thanks! _M
This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
