mhellman Tue, 04/15/2008 - 08:31
User Badges:
  • Blue, 1500 points or more

I have the IDS appliance, but it should be doable. I've tried various engines and I'm not making any progress with my testing though. I'm looking to duplicate the following snort rule, can a Cisco sig analyst help us out here?:

policy.rules:# alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"POLICY download of executable content"; flow:to_client,established; content:"application/octet-stream"; nocase; pcre:"/^Content-Type\x3a[\x20\x09]+application\/octet-stream/smi"; pcre:"/(\r?\n){2}MZ/sm"; reference:url, classtype:policy-violation; sid:11192; rev:1;)

fwiw, the above rule isn't complete either, but it's a start.

PronetMSSP Thu, 12/09/2010 - 05:52
User Badges:

Did you find an answer to this question?  We are looking to do the same thing here and I'm just starting to research it.

Thank you,

mhellman Thu, 12/09/2010 - 06:33
User Badges:
  • Blue, 1500 points or more

I don't remember how I tested and why it wan't working, but it should be pretty easily actually using the service HTTP engine.  I would focus on using the content-type header in the response (versus looking at the GET request).  Clone 5343-0.  Change the regex to something like this:

[Cc][Oo][Nn][Tt][Ee][Nn][Tt][-][Tt][Yy][Pp][Ee][:][ \t]+[Aa][Pp][Pp][Ll][Cc][Aa][Tt][Ii][Oo][Nn][/][Oo][Cc][Tt][Ee][Tt]-[Ss][Tt][Rr][Ee][Aa][Mm]

FWIW, there are many more content-types that are "executable", but that's a big one.  You'd need a rule for each content type. And of course this won't work for HTTPS or pure FTP downloads. For a start on some others, try here:

PronetMSSP Thu, 12/09/2010 - 06:47
User Badges:

Thank you for the quick reply and for the information.  I'll start digging further into it and create a test signature.

Thanks again,


mzeiser Thu, 12/09/2010 - 06:51
User Badges:
  • Cisco Employee,

There's two ways of doing this.

a) engine service-http

This engine only inspects traffic going FROM a client TO a webserver. An uri regex of [.][eE][xX][eE]\x20 should do just fine to keep clients from requesting a file like that.

b) engine string-tcp

inspect traffic coming FROM #WEBPORTS

Just the like the snort rule a [\r\n][\r\n][\r\n][\r\n]MZ should do. If you watch the download of an .exe in Wireshark, you'll see the 2 \r\n followed by the first bytes of the exe, which in Windows usually starts with 'MZ'. Btw, since it's the same signature bytes for .dlls, this regex would also block the download of .dll files

Hope that helps


IPS Signature Team

PronetMSSP Thu, 12/09/2010 - 08:26
User Badges:


Thank you very much. I imagine option A will work just fine but I'll have to look into these and see which option will be better for us.  This will mainly be used to block malware from downloading executables but will also help stop the occasional user download.


mhellman Thu, 12/09/2010 - 08:59
User Badges:
  • Blue, 1500 points or more

doh! I think I knew that at one time. That's really unfortunate, but that would probably explain why my tests didn't work back then. Use a GET request is not particularly useful.  The content-type is what is primarily used by the browser to determine how the file is treated and there may not be a filename at all in the GET line (i.e. ?getfile=1 can return a file).  go with option 2.


This Discussion