Snort rules - how to start?!?

How does one start looking for payload portions uniquely identifying base64 emails, to be able to use them as starting point of snort rules (i.e. what part of a MIME base64 encoded payload would one consider as possible "content" option for such rules)?

TIA,
Stef

My initial message was posted on the antivirus forum, where the question clearly related to the subject of that forum. Reading it again here, where the admin has moved it (this forum), the original did not make full sense, anymore - so, just to clarify what I meant: where in the payload would one look when starting to uniquely identify a new virus "signature"?

It makes sense in that people with experitise in writing snort rules (IDS) would be able to help. Hence, the move from AntiVirus to IDS.

[Addenum]

You may want to do a search through the forums for the word "snort" as there have been some specialized rules written for various email based viruses and these may help. In addition, it should identify the "custom rules experts" of AO.

Stef: Why bother? Seriously..... If this is a corporate environment you want to do this in then the sheer volume of positives you will get are simply a waste of logfile space and the threat should be mitigated in other ways that actually blocks them and that mitigation method should be able to report them if it's a reporting issue you have. If it's a personal machine then you are going to see it on your AV anyway.... So what's the point?

There is a generic rule out there.... I can find it if you want, that simply reports _any_ file type in mail that is potentially harmful.... I run that rule in my corporate environment on an internal sensor. But it's only there to alert me that the firewall failed to strip it from the email anyway.... Belt and braces approach but it makes me feel all warm and fuzzy... ;)

If you want to do this for learning alone then the way to create your snort rules is to start with a known issue, in this case Base64 encoding, and run the same pattern numerous times. While you do this run a packet sniffer like Ethereal to capture the actual SMTP or POP packets as they run to the server or the client. Then you need to take the data packets and examine them thoroughly. What you are looking for is the common pattern - somewhere in the entire data transfer there is _always_ be XXXXX somewhere in one of the packets. Now you have to be a tad careful.... 'cos "rcpt to:" will be in any email so that wouldn't be a good match.... so if you don't understand the underlying protocol then you need to research that first to see what is "normal". What you are looking for is the _unique_ or that which is so uncommon that the false positives don't make you ignore the alert altogether.

I doubt that there is a "rule" to catch Base64 encoding since it is too broad of a rule and the packets that imply the encoding probably do not carry the "signature" you are looking for. This complicates the rules and the subsequent alerting quite significantly more difficult since you need to try to start stringing packets together using the dynamic rules.....

All that probably wasn't a huge amount of help but I hope you get the picture.....

Admin: I perfectly understand the reasoning for the move. My second email was just to clarify a little the original posting. I have done a search for snort, and - obviously - stumbled across some rules. See below why I asked my question in the antivirus group, to begin with.
Tiger Shark: Thank you for suggestions. I have gone through the same thought process as you recommended, and I feel I need even more clarification for my original question:

I am not worried about existing/known viruses (virii?!?) or a specific attachment framework. What I have is a honeypot, setup such that it appears as an open-relay, and holding a few fake accounts (as honeytokens, if you will). Obviously all email attempted to be relayed through it, as well as directed to its local accounts, is - by definition - spam of some sort, and - most of the time - virus relayed from infected systems. What I want to do is to be able to write some rules for the attachments containing viruses and spam, if those are not already known. The problem I am having is to learn where to start from, in writing such rules (e.g. the attachments are base64 encoded - which part is giving uniqueness to it, and how is it better to approach it with snort: as base64, or decoded first, then apply a pure hex pattern ?!? ... I do not even know if this makes much sense).

Then - my other issue (which I have not asked about, in the beginning) is: if I would know where to look for specific things in base64 attachments, I could - perhaps - identify spam based on some characteristics in the payload may also help (I know - there are tons of rules right now - I am just contemplating other options here). Right now I get roughly 4000-5000 relay attempts/day, with two main characteristics in the payload, which I am having a hard time understanding how to approach in writing snort rules for.

The end result of the above? If I could write some snort rules "on the fly" - I could also hope to update my firewalls or border routers, based on volume and perceived criticality of emails, to give some relief (temporarily) to the existing mail filters I have ... or to the antivirus gateway not_yet_updated_by_the_vendor_with_latest_signatures.

Thx,
Stef

The first thing you need to consider is that mime encoding takes three 8bit chunks of data and converts it into four 6bit parts usind '=' for NULL data. Now an email is transit can be broken into many segments based on MTU and networking factors allong the way you cant really be sure how it will arrive.
(heres a link to how mime work and ill build off an example there)
http://www.thedbcommunity.com/code/base64.htm

You cannot build a rule based off Mime encoding. We need to consider the actual virus/offending content itself. if you have it in mime you can use a tool like mpack1.6 which will unmime or mime depending on your needs. Now what I like to do is use a hexeditor on the unmimed content but I also dissassemble the virus itself to find specific content to this virus in assembly. What you need to find is something specific or unique to this virus. For this example lets use 'Liz' as our offending content. If 'Liz' were to be encoded directly its mime text would be TGl6

But what we need to consider is the different possibilities of 'Liz' being broken up before encoded and this requires looking at the surrounding content of 'Liz' so in this case lets make it simply 'aaLizaa'. Now it is possible that when encoded it could use aaL,aLi,Liz,iza,zaa. So this can be broken into 3 pairs {(aaL,iza),(aLi,zaa), or (Liz). So you would need to determined the possilbe mime encoding for each of the 3. I leave the first 2 up to you and we know the third is TGI6.

So we can now devolp 3 rules to catch this mime encoded conent in the virus.ie one being
alert tcp any any -> any 25 (content:"TGI6"); //just a basic example not a complete rule

It also a good idea to find the biggest unique pattern you can. And muliple unique patterns serve even better to reduce the chances of false positives within your rule.

Now I started this but had to rush so I short changed it and may have made a mistake in there. But that gives you a basic framework for you to play with. I think after palying with this for a while you will learn more of what to search for and different combination of possibilites.

Also I think devopiing your own rules is way worth it. I think I have developed rules that are far better than the snort rules, Ive also develped rules for major exploits that sourcefire never has. Snort is great but sourcefire really sucks about generating rules nowadays.

Stef: You seem to want to either detect viruses that are currently unknown or, detect patterns that might indicate an unknown virus. Either is a pretty tall order old chap if you are talking about an IDS... ;)

It seems to me you are discussing a corporate environment with your mention of updating firewalls and border routers. This being the case you are implying that you are either going to block the address at the firewall when "questionable" content is found which is feasible with many firewalls or that you are going to block the content at the firewall. The implication of the second possibility is that your firewall can filter on content.... That being the case - block it by file extension in SMTP attachments. Don't worry about .doc, .xls etc., (but do block mdb and mde IMO), since they seem to have become somewhat passe where the virus authors are concerned and probably won't present the most dangerous threats in the future unless someone, (M$), comes up with a wonderful new "data sharing/access" method... At that point, block the offending extension too till the threat subsides and/or your secondary defense, (the Mail AV), is updated with the signature and fix.

I dunno.... maybe I'm missing something but it seems to me like trying to use Snort to mitigate an issue that it appears that you could mitigate more successfully in another way could result in more problems, (not to mention work on your part), than is safe or necessary.

Can you give me more information if I am "not getting it"... ;)