can ips be used to block *.exe downloads

[mark007uk]

Hello does any one know if the IPS signatures on an ips module in an ASA can be used to stop *.exe downloads

cheers for any info

[mhellman]

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,www.microsoft.com/smallbusiness/resources/technology/security/practice_safe_computing_and_thwart_online_thugs.mspx; classtype:policy-violation; sid:11192; rev:1;)

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

[PronetMSSP]

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]

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:

http://mimeapplication.net/octet-stream

[PronetMSSP]

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

Thanks again,

Cory

[mzeiser]

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

Martin

IPS Signature Team

[PronetMSSP]

Martin,

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.

Cory

[mhellman]

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.