My logic of blocking certain sorts of attachments outright

August 28, 2016

Once we started knowing more about what sort of attachments our users get (both good and bad), as we now do, we drifted into the obvious next step of starting to block some of them. Our current set of blocks are conservative and have basically been drive by seeing what our commercial anti-spam package already dislikes. Is it identifying basically everything with a single .js file in a ZIP archive as bad? Well, let's just go ahead and block those outright.

Now, there's a perfectly sensible question that one could ask here: if our anti-spam package is already detecting this stuff as bad, why bother doing anything to preempt it? We're essentially going to some amount of effort to duplicate work that's already being done for us.

(How we do this may result in somewhat less load on the overall system, but our external email gateway system isn't particularly burdened in the first place so this isn't something we care about.)

My biggest reason for arguing in favour of general early blocking is simple: it's unwise to count on recognizing all malware. Unless the commercial package we use has adopted rules that are just as general as ours (and we can't tell, it's a black box), it's using some sort of signatures or pattern analysis or recognition system to pick out malware. It may be batting a thousand on those malware .js files now, but there's no guarantee that this will always be the case; at some point in the future the .js malware may mutate so that the package doesn't recognize it for a while. So where we can use them, our general blocks act as a safety backstop to the more nuanced detection that the commercial package is doing.

(There are cases where we can't use general blocking. Our users get a certain amount of legitimate Java .jars and Office documents with macros, so we can't block either of those outright despite both of them being vectors for malware. Instead we have to cross our fingers that the commercial package's recognition is good enough and our users will be sufficiently suspicious of anything that does slip through.)

In our situation a secondary reason is to shield the commercial anti-spam package from having to apply potentially buggy code to potential malware files. The package definitely has had bugs in the past and probably will in the future; if we're sufficiently confident that we don't want certain things no matter what, we can sidestep any potential problems in the package's parsing and recognition systems by just refusing things first without peering into them.

(Of course if you start thinking too much about this you wind up gibbering in the corner. The infosec world and AFL have been very good at blowing giant holes in complex parsers, which is exactly what pretty much every anti-spam and anti-malware system has.)

Written on 28 August 2016.
« Why ZFS L2ARC is probably not a good fit for our setup
Phones and tablets are going to change what sort of passwords I use »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Aug 28 00:43:16 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.