Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 439
  • Last Modified:

Guideline for zipped & non zip files to be excluded from scanning

Trend's Deep Security has given us list of files (DB, certain Sharepoint files etc) to be excluded from
their AV scan as they will cause issue.

Trend's support has advised that zip files (esp those with many files zipped into one zip) will take
more resources to be unzipped, scanned & was told Deep Security will rezip it back.  They advised
that malware/viruses usually tend to infect smaller files & rarely infect big files but did not give
specific sizing of the files & the size of zip & non-zip files that will trigger systems performance

Anyone / any other AV products has any white paper / guidelines on
a) what's the file size above which malware generally won't infect
b) at what sizings (& number of files in a zip) that it's recommended
    not to scan so as not to affect performance.  In particular I have
    customer/tenants that use our facilities & publish zip & non-zip
    files & I would say it's fair if it takes 30 seconds to scan a published
    file, above which, the user will get unhappy

We run DS on-demand and realtime scan in Windows 2008 R2,
RHEL 5.x/6.x (realtime only) & Solaris x86 (on-demand)
  • 3
  • 2
3 Solutions
Hi, personal opinion I don't think this is possible to set since malware constantly evolve/recode their scripts hence the reason we have updates to our our virus detection definitions,
if a weakness can be found they'll find it no matter the size.
a) what's the file size above which malware generally won't infect<< no such thing
b) at what sizings (& number of files in a zip) that it's recommended not scan, well Trend recommends for Compressed File Handling see Compressed files scanning restrictions:
btanExec ConsultantCommented:
I don't suggest we go by file size to scan but for performance sake based on AV, i do consider that their default is the best practice specific to their processing. There is no so called best practice as it is specific to the AV used.

E.g. in Symantec it has the Max File Size is 2 GB per File and if the File is a Container-File like ZIP etc. the unzipped size (including zip in zip) must not exeed 30 GB (30719MB).

But really do we even have process Files with Size up to 5 MB which is already consider quite huge already. I know the email attachment can go bigger than this but not often we do that and like need file transfer etc. I say the AV should not have limit though but earlier mentioned - take there recommended or default and tune as needed to your h/w and throughput. I do not see magic number appearing immediately but minimally you has the granularity to customise the sizing (this actually also complicate administrative task, go simple and have the biggest consumer in organisation to test out on their norm biggest file load then.

Nonetheless, you can check out the practice guide from TM

1 -(pdf) DSR page 34, it stated the recommended action and setting.
(Recommended Real-time Scan Configuration )
Maximum size of individual extracted files - 30
Maximum Levels - 2
Maximum number of files to extract -10
OLE Layers to Scan - 3

(Recommended Scheduled Scan Configuration )
Maximum size of individual extracted files - 60
Maximum Levels - 3
Maximum number of files to extract -10
OLE Layers to Scan - 3

(Recommended Manual Scan Configuration )
Maximum size of individual extracted files - 60
Maximum Levels - 2
Maximum number of files to extract -10
OLE Layers to Scan - 3

2-  (pdf) http://docs.trendmicro.com/all/ent/pp/v2.1/en-us/pp_2.1_bpg.pdf 
- See the "Advanced Options (Scan Restriction Criteria)" for
Decompressed file count exceeds ( default value is 9999), Size of decompressed file exceeds (default value is 100MB), Number of layers of compression exceeds (default value is five (5)), Size of decompressed file is “x” times the size of compressed file (default value is 1000)

Also do note that scanning a compressed file that might cause a Denial-of-Service (DoS) attack. A Denial-of-Service (DoS) attack happens when a mail server’s resources are overwhelmed by unnecessary tasks. So it is wise to also prevent AV from scanning files that decompress into very large files helps prevent this problem from happening. Hence those field do play a part  - just need to profile and tune as you go along ...
sunhuxAuthor Commented:
This is quite a 'tricky' requirement: as the users published their files
& will need to view the outputs of the scan results on-the-fly, I would
say 20-30 secs of scanning is the max they can wait before they got

So be it zip or non-zip files, I'm trying to work out what is this 'magic'
figure of the file sizing, above which the scan will take more than 20
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

btanExec ConsultantCommented:
indeed tricky but I do not think there is a magic no unless you try it out with baseline using the same spec as user machine. You have to do it for manual scan since user trigger the scan. For a start, try the recommended,

- if the time meet the 20-30sec then I suggest you go size 10% lower for buffering as there can be background process eating resource - it is minimal impact though.
- if the time is beyond 20-30sec, go for 50% lower and do another baselining and likewise if it is within the acceptable limit then have another 10% size lower.
Unless the support can suggest some perform figure which normally they will not as they will say environment specific and many dependency. So you likely have to do it yourself.

there is some old paper on DS comparison with some performance spec but timing of scan is not stated though (see "on demand scan"). it stated some file size prepopulated, for 50VM and took 14hr 16min

best practice guide for DS 9
sunhuxAuthor Commented:
Just thought of MS Excel (& a recent Powerpoint vulnerability) that may
have malicious macros : Ok, the largest Excel/Ppt file I've seen is 20MB.

We may have users uploading Excel to Sharepoint servers/VMs, so I
guess 20 MB is a decent magical number
btanExec ConsultantCommented:
yap test it as form of profiling and I should see this magic no isnt going to pose any issue to the TM DS unless support advice otherwise

Featured Post

Who's Defending Your Organization from Threats?

Protecting against advanced threats requires an IT dream team – a well-oiled machine of people and solutions working together to defend your organization. Download our resource kit today to learn more about the tools you need to build you IT Dream Team!

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now