6 Replies Latest reply on Dec 6, 2016 11:24 AM by ztamas

    Rule to scan large files

    ztamas

      Hi All,

       

      When the web gateway scans large multiple archive files the scanning of these kinds of files takes too long. I'd like to scan these files only once with the same signature independently from the source or the destination of the files. I created a rule that check the file hash and only scan the whole file (with composite opener and GAM) only once a day basis of the hash. I have tested the rule in a lab environment and it seems it is working as I wish.

       

      Could someone help me to validate the rule? I’d like be sure there is no unexpected side effect of the rule before I use it in production environment.

       

      Thanks!

      Regards,

      Zoltan

        • 1. Re: Rule to scan large files
          jacek

          I can't see in your rule set criteria for scanning only "large" files.

          • 2. Re: Rule to scan large files
            ztamas

            The screenshot is created about my test WG where the file size dosn't matter.

            • 3. Re: Rule to scan large files
              Jon Scholten

              Hi Zoltan,

               

              I saw the same question coming from an SE internally, I'm guessing you're the source.

               

              I like how you did this. Based on your rules, if we dont see the hash within the defined limit (Default), that value should be removed.

               

              Where/when are you adding the file hash to PDStorage? This is important because if you're adding the hash in the response cycle, MWG could find a virus in the embedded cycle. If this happened, we'd be whitelisting a hash which has a virus inside of the object.

               

              Adding the hash in the Logging Cycle (Log Handler) is best because logging happens after the transaction occurs (rather than midway through it).

               

              I built a version of this which maintains a list of hashes, and we're appending to that list in the logging cycle if no virus was found. The list of hashes is flushed after a GAM update is performed rather than every 24 hours. Flushing of the list is done in the error handler cuing on a certain incident ID.

               

              Best Regards,

              Jon

              1 of 1 people found this helpful
              • 4. Re: Rule to scan large files
                ztamas

                Hi Jon,

                 

                Your guessing is correct. I was the source of the request.

                The original idea of the rule was not mine. I found a similar rule on the community. (Thanks for it for fwmonitor.) https://community.mcafee.com/message/260210

                 

                Thanks for your advice!

                The Logging Cycle is a better place to calculate a file hash. I redesigned the rule as you suggested and it is working perfectly.

                 

                 

                 

                Thanks!

                Regards,

                Zoltan

                • 5. Re: Rule to scan large files
                  Jon Scholten

                  Hi Zoltan!

                   

                  You will not want to caclulate the hash in the logging cycle (it wont work). You will and to calculate it in the response cycle to a user defined property.

                   

                  The order would be the following:

                  1. Calculate the hash of the response body in the response cycle -- User-Defined.ResponseBodyHash = Body.HashSHA1 (Example)

                  2. In the Logging cycle, if no virus was found (throughout the file -- response cycle or embedded), add the response body hash (User-Defined.ResponseBodyHash) to your PDStorage

                   

                  Best Regards,

                  Jon

                  • 6. Re: Rule to scan large files
                    ztamas

                    Hi Jon!

                     

                    The hash calculation is working for me in the logging cycle the but the filters are not working perfectly.

                    Your suggested resolution is better.

                    Thanks for your help!

                    Best Regards,

                    Zoltan