04-14-2008 11:31 AM - edited 03-10-2019 04:03 AM
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
04-15-2008 08:31 AM
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.
12-09-2010 05:52 AM
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,
12-09-2010 06:33 AM
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:
12-09-2010 06:47 AM
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
12-09-2010 06:51 AM
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
12-09-2010 08:26 AM
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
12-09-2010 08:59 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide