One of my HIPS rules specifically blocks any access to a *.torrent file, for obvious reasons. Going through my HIPS logs today, I see the following event:

It’s fascinating to think that WoW uses bittorrent to manage itself, just not on one of my work machines, thank you very much.

I used to use Boxtrapper to control who could send email to an uber-secret email account, that Wordpress would check and post any email in that account.

For some reason my hosting service removed Boxtrapper and of course the spam found my inbox and was subsequently posted here on my blog.

To replace Boxtrapper, they’ve provided generic message control filters, so I set up a rule to allow email from my email accounts as the first rule and the second rule is this:

where from matches regex ‘.*’ bounce

So now if you aren’t on my approved list, you’ll get an NDR that simply states:

A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:

This will do the trick, at least until my provider decides to pull the plug on their message control filters.

Thanks again to every who notified me using Twitter, email, and my contact page on the blog and a big thanks to Martin McKeay for a very effective and creative way of getting the word to me. Good lookin’ out.

Belay on.

Thanks to everyone who let me know about the blog spam. I believe it is coming in through the post-from-email feature. I don’t have time right now to dig into it, I’m off to get belay certified, but I’ve disabled that feature. Hopefully that puts an end to it.

Thanks again.

Take ‘em for what their worth; this is a collection of events logged from 277 hosts located in 12 different office locations with five unique, central AV servers managed by five different IT departments.

The statistics have been collected over 11 days:

The failure to open a file is attributed to, according to the event log, “extraction errors encountered by the Decomposer Engines” which I assume are the engines that translate the file to something the AV software can scan, whether the file is an executable file, compressed file, text file, etc.

Now, is it really possible that on 277 laptops there have only been a total of 7 pieces of malware that have made it all the way to the machine? I’d love to say this number is accurate and the result of defense in depth, but I’m not ready to say that just yet.

What countermeasures do we have in place that would help?

1. Strict email attachment filters based on file extension alone
2. ‘Course grain’ AV at the spam gateway, before the email hits our servers
3. ‘Fine grain’ AV at the email gateway before the email hits the inboxes
4. IPS units protecting web browser attacks, but only while hosts are on our network
5. Behavioral HIPS on all laptops

Does that battery of defenses look like something that could reduce the number of threats that make it to our laptops to only 7 in 11 days for 277 hosts?

That’s a pretty good success story if its true. However, given that we have 1,253 cases of a failure to open a file, we have possibly 1,253 additional viruses that we can’t detect, not to mention the 969 alerts that the AV software is failing to auto-protect some hosts.

But as my grandpappy always says; if it seems too good to be true, it likely is too good to be true.

*The AV software logs multiple events on a single host, therefore I’ll have to distill these events to find an accurate count of the number of unique hosts or files affected.

Last week I struck a cord with a few people when I (once again) complained publicly about the short-comings of AV. I’ve gone on record claiming the current model is broken, so what do I think will help fix it? Below are some of the ideas I’ve had for the future of AV.

1. Shim the web browsers, either between the Internet and the browser (preferred) or between the browser and the OS so that the AV app can keep its fingers around the browser’s throat and control it.
2. Develop vulnerability protection into the browser shim that acts as a virtual patch rather than traditional AV models that look for malware. This will be much more effective at stopping variants than malware protection is.
3. Include a killbit feature to snipe malicious CLSIDs. Granted, this is signature-based but we need a stop-gap in place while heuristic or HIPS-like technology catches up.
4. Utilize P2P-like communication between AV clients within the enterprise. If a host detects a malicious file, have it communicate an MD5 hash of the file to all other hosts and prevent access to that file. This will also help when there is disparity of definition versions within the enterprise.
5. Take advantage of worms that check for a local infection by duping it into thinking the host is already infected. For example, Nimbda first checked if the local machine was infected. If AV could simulate infection automatically, it could prevent an actual infection. AV is pretty useless against worms until a payload is delivered. The ability to simulate an infection could help in that phase of a compromise.

The key is for AV R&D teams to gather in a room with a white board and start a brain-dump, thinking out of the box, leaving no trivial idea unspoken.