CSSCurrent en:File type filter
About
The Cryptshare file type filter allows administrators to exclude specific combinations of media types and file extensions (File types) from transfers.
If enabled, the file type filter will process uploaded files, by determining their media type and extension and checking this information with the provided file type list. File types that are not allowed will be excluded from the transfer while notifying the user about the administrative restrictions. File types that are not part of the used file type list are processed, depending on the currently selected filter mode.
Another functionality of the file type filter is the so-called in-depth analysis, which allows to analyze the content of container files for their file type. However, only the file type of the embedded files is checked, so there is no extended analysis of the file's content!
What is a file type?
A file type is a combination of file extension (e.g. "pdf") and media type (e.g. "application/pdf") of the file. While the file extension can be chosen arbitrarily and therefore easily manipulated, the media type describes the content of the file (The List of available media types is published by the IANA).
Depending on the file category, there may be multiple file types for a file family. For example, in the family of Word documents, there are several combinations of file extension and different media types that result in different file types.
What is a file type list?
A file type list contains a set of file type entries that describe whether the associated file types should be treated as "allowed" or "forbidden".
Multiple lists can be maintained to use different file type filter configurations for different policy rules. For example, a less restrictive file type list could be used for internal transfers, while a highly restrictive list is used for external transfers.
File types detected during a transfer that are not part of the currently used list are treated as either "allowed" or "denied" depending on the current filter mode.
Enable file type filter
To enable file type filtering the following steps have to be followed:
- Navigate to Transfer-Processing -> File Type Filter
- Enter a custom name for the new filter list in the input field under Add new file type list and click on the "Add" Button.
- A new tab is displayed where file type entries have to be added to the file type list. You can find more information in the section file type list
- After saving the changes, select the policy rules where this filter list should be used. This can be done via the Policy Wizard or setting the Policy Settings.
In case of multiple policy rules using different filter lists, conflict solution has to be configured. Please refer to the section Policy Conflict Solution.
Filter mode
As already described, the files are filtered using the file type list that is assigned to the policy rule applied in the current transfer. The file type entries in the list are evaluated and a decision is made based on the available data.
However, it can also happen that file types are recognized that are not part of the currently used file type list. These file types are handled depending on the filter mode. The file type filter currently offers two modes that can be set globally for all file type lists of the system: The strict mode and the tolerant mode.
Strict mode
By default, the selected filter mode is the "strict mode" that treats all file types that are not part of the used list as "Denied". This behavior provides the highest level of security, since renaming or unrecognizing malicious or disallowed files results in other file types, therefore being filtered as "Denied". However, the strict mode increases the administrative overhead when a wide number of file types need to be set as "Allowed".
Tolerant Mode
The "tolerant filter mode" handles unknown file types as "allowed" mostly. With this mode, a list of file types can be defined which should be rejected by the file type filter, other file types are handled as "allowed".
This mode significantly reduces the administrative effort, but at the expense of security, as dangerous files that were overlooked when compiling the list of forbidden file types are not rejected by the file type filter.
In order to increase the security of the tolerant filter mode and to be able to filter out renamed or unrecognisable files better, individual parts of the file type filter definition are also taken into account in the filtering, i.e. so a matching file extension or media type may lead to denying a file.
The check whether a file is treated as allowed or denied is carried out in detail as follows:
- If the recognised file type (file extension+media type) is specified as "Allowed" in the file type list, the file will be allowed. Otherwise...
- ...if the recognised file type is specified as "Denied" in the file type list, the file will be denied. Otherwise...
- ...an entry already exists in the file type list for the file extension or the media type which is set to "Denied", the file will be denied. Otherwise...
- ...the file will be allowed.
With this procedure, dangerous file types that have been included as prohibited in the file type list can also be identified and filtered out in many cases.
File type list
Here, the file type entries of the file type list can be managed and the settings for the in-depth analysis can be adjusted. Besides adding new entries, there is the possibility to import the content of an exported list via a CSV file, as well as to export the current content to a CSV file. File types that are not part of the current list are handled according to the current filter mode.
The behavior of the file type list in combination with the currently set filter mode can be seen in the following table
| strict mode | tolerant mode | |
|---|---|---|
| File type entered as "allowed" | allowed | allowed |
| File type entered as "denied" | denied | denied |
| File type is not part of the list and there
there is no other forbidden entry with the same file extension or media type |
denied | allowed |
| File type is not part of the list but
one or more forbidden entries exist with the same file extension or same media type |
denied | denied |
Default values
A newly created file type list contains the file type eml - message/rfc822 as "allowed" by default. This file type must be allowed to send confidential messages via the Cryptshare server. If this is not desired the file type can be disabled for confidential messages.
Deleting a file type list
When a list that is already assigned in policy rules is deleted, the assignments are deleted as well. Accordingly, the file type filter will be disabled for these policy rules. Deleting a file type list can be initiated by pressing the "Delete" Button 
. The deletion cannot be undone.
Export
The content of the file type list can be downloaded in a CSV file in order to import it again, e.g. on another system or in another list. The export is initialised via the "Export" button 
.
Import
An existing list of entries can be added to the file type list via the CSV import. The import window can be opened via the "Import" button 
. A CSV file can be selected and uploaded via the "Select" button.
The upload will replace all existing entries of the file type list with the content of the uploaded CSV file!
Format of the CSV file
The CSV file used for importing filetype list entries has to contain a header line that contains the following entries: File extension;Media type;Selection;In-depth analysis. After the header line all the entries that should be imported can be added. The following example would allow confidential messages and different archive filetypes and deny executable files.
An example file can be downloaded here:Datei:Example CSV Import.csv
"File extension";"Media type";"Selection";"In-depth analysis"
"eml";"message/rfc822";"1";"0"
"exe";"application/octet-stream";"0";"0"
"zip";"application/zip";"1";"0"
"bz";"application/x-bzip";"1";"1"
"7z";"application/x-7z-compressed";"1";"1"
| File extension | Media type | Selection | In-depth analysis |
|---|---|---|---|
The extension of the file type.
(e.g. "zip", "exe", ...) |
The media type
(e.g. application/zip). |
Denied (0) OR
allowed (1)
|
Not active (0) OR
active (1)
|
Optional delimiter definition
If the CSV file was written using a different delimiter than a semicolon, you need to define which delimiter was used for the file by adding a first line with the following definition:
Example ("," as separator):
sep=,
"File extension";"Media type";"Selection";"In-depth analysis"
"eml","message/rfc822","1","0"
"zip","application/zip","1","0"
"bz","application/x-bzip","1","1"
"7z","application/x-7z-compressed","1","1"
Adding file type
You can manually add individual "extension"-"media type"-combinations to the file type list. Please note that manually added entries are set to "Allow" by default.
If you are in possession of a file that should be handled by the file type filter and do not know the media type, you can upload this file to the Cryptshare server. The Cryptshare server determines the file extension and the media type and automatically adds them to this list.
If you are not in possession of a file but know the file extension and the media type, you can also add both values manually to the list.
The window for adding a file type can be opened using the corresponding button directly below the file type table.
Adding file types automatically
To simplify the introduction phase of the file type filter, there is an option to have the system automatically add file types that are not yet part of the file type list used in the transfer to all file type lists. If this option is enabled, unknown file types will be added to the lists by the system depending on the active filter mode:
- In strict mode, the file type is added as denied to the file type lists
- In tolerant mode, the file type is added as allowed to the file type lists
Notification settings
The system offers the administrator the option to be informed about newly recognized file types via e-mail. This can be helpful, especially in the introductory phase to be informed that users cannot send certain file types or that the file type filter list was extended with new entries. The email will contain all newly added file types that have been added by the system since the previous notification was successfully sent and will be sent to the configured administrator emails. The frequency of the notifications can be configured by the administrator as desired:
- never: No notifications are sent
- daily at "XX:00": The notifications are sent daily at the set time.
- hourly: Notifications are sent every hour
- immediately: When a new file type is detected and added to a list, the notification is sent immediately
If no file types were detected in the set time period, no notification will be sent at the specified time.
In-depth analysis
Container formats allow embedding files (e.g. archive files, office files, PDF, ...). They can be extracted and analyzed for their embedded content. The file type filter allows you to turn on in-depth analysis for specific container types.
Important: The in-depth analysis only checks for the file type of the embedded files and not for malicious content, etc.
Since the contents of the container formats are extracted and analyzed during in-depth analysis, this mode requires additional system resources. Depending on the desired file size and the amount of files that should be allowed in container files, the required computing power, the disk space, and the RAM requirements increase. Therefore, in-depth analysis should only be used in systems that have sufficient additional resources available.
Limit values
Container files can contain any number of files. This means that they may contain other nested container files (e.g. a zip file can contain another zip file that contains an exe file). This causes them to be recursively processed by the Cryptshare server during in-depth analysis. Attackers can construct container files in such a way that they have a minimum size when compressed (e.g. 42KB) but require a multiple of the size when fully unpacked (e.g. 4 PB). An archive file constructed in this way is also called an archive bomb. To avoid system overload and denial of service attacks when analyzing container files, certain limits must be set by the server.
File size limit per embedded file
This is the maximal size a single embedded file within a container format can have. When at least one embedded file exceeds this limit, the container file will be removed. Setting this value to 0 allows use of embedded files of any size.
Max. analysis depth
This is the max analysis depth for nested container files. When the depth exceeds, the container file will be removed. Setting this value to 0 allows unlimited nesting.
Max. amount of embedded files per container file
This limits the amount of embedded files per container file. When the container file contains more files than this number, the container file will be removed. Setting this value to 0 allows unlimited amount of embedded files.
Defaults
The following limits are set as default for the in-depth analysis of a list
| Limit | |
|---|---|
| File size limit per embedded file | 100 MB |
| Max. analysis depth | 1 Layer |
| Max. amount of embedded files per container file | 10 Files |
The number of possible container files increases exponentially with each layer.
Thus, if the default values are changed to the following values...
...a maximum number of files of 1003 files, i.e. a total of 1,000,000 files would be possible.
Handling of password protected container files
Since password-protected files cannot be read without the associated password, the in-depth analysis cannot be performed for such files. Therefore, password-protected container files are rejected with a corresponding error message.
Office 2007+
Office 2007+ files are based on the OpenXML format. When such a document is encrypted, the actual media type can no longer be recognized. Instead, a general media type for encrypted Office formats is detected (application/x-tika-ooxml-protected) . In this exception case, the encrypted file will be rejected as "forbidden" by the file type filter unless otherwise set in the file type list.
Supported container formats
| File extension | Media types |
|---|---|
| bz2 | application/x-bzip2 |
| tbz2 | application/x-bzip2 |
| docm | application/vnd.ms-word.document.macroenabled.12 |
| docx | application/vnd.openxmlformats-officedocument.wordprocessingml.document |
| dotm | application/vnd.ms-word.template.macroenabled.12 |
| dotx | application/vnd.openxmlformats-officedocument.wordprocessingml.template |
| gz | application/gzip |
| tgz | application/gzip |
| jar | application/java-archive |
| eml | message/rfc822 |
| application/pdf | |
| potm | application/vnd.ms-powerpoint.template.macroenabled.12 |
| potx | application/vnd.openxmlformats-officedocument.presentationml.template |
| ppsm | application/vnd.ms-powerpoint.slideshow.macroenabled.12 |
| ppsx | application/vnd.openxmlformats-officedocument.presentationml.slideshow |
| pptm | application/vnd.ms-powerpoint.presentation.macroenabled.12 |
| pptx | application/vnd.openxmlformats-officedocument.presentationml.presentation |
| 7z | application/x-7z-compressed |
| tar | application/x-tar |
| tar | application/x-gtar |
| xlsm | application/vnd.ms-excel.sheet.macroenabled.12 |
| xlsx | application/vnd.openxmlformats-officedocument.spreadsheetml.sheet |
| xltm | application/vnd.ms-excel.template.macroenabled.12 |
| xltx | application/vnd.openxmlformats-officedocument.spreadsheetml.template |
| zip | application/zip |
Known limitations
Due to technical limitations, scanning of the supported container formats may not be supported in some cases. In case in-depth analysis encounters a file with an unsupported container format, the file will be denied and removed from the transfer.
7Zip compression method & compression strength
7Zip allows you to create archive files with different compression methods and compression strengths. The in-depth analysis of the file type filter supports most compression methods and compression strengths. The following list shows the supported and unsupported combinations:
| Compression method | Compression strength | Supported |
|---|---|---|
| bzip2 | <= Maximum | 
|
| lzma | <= Maximum |
|
| lzma2 | <= Maximum |
|
| ppmd | all | 
|
Strict Open XML (Office 2007+) documents
In-depth analysis of Strict Open XML files is also not supported. In order to send office documents, the user has to save their document in the default format.
Policy Settings
As described before, a filetype list must be assigned to a policy rule to enable filtering based on the list. This can be done manually via the policy wizard. If you want to assign a file type list to the created policy rule by default when creating new policy rules, you can set a standard list using the selection dropdown. The default list is also assigned when "Load Defaults" is selected on the "Policy Settings" page.
If no list is selected as the default, new policy rules are created without an assigned file type list.
When a file type list is used within one or more policies, a panel is displayed showing all these policies
Conflict Solution
In the event that multiple policies apply to a transfer, two scenarios exist:
- Two policies are in effect for the current transfer. Policy A has assigned a file type list, policy B has not. In this case, the file type list from Policy A is used.
- There are two or more policies for the current transfer that have different file type lists assigned to them. In this case, according to the prioritization defined in the Policy Conflict Solution, it is decided which list will be used for the transfer.
If you want to treat internal transfers (i.e., transfers from one employee to another) separately from transfers between your employees and external contacts, you should note this article
Common scenarios
Scenario 1: Strict mode + in-depth analysis switched off
The following assumptions are made for this scenario:
- The administrator creates a file type list that contains the file types for PDF, Word and Excel documents as allowed.
- The list is assigned to all effective policy rules.
- The global filter mode is set to "strict".
User A wants to send a "forbidden" .exe file to user B. He adds this file to the transfer starts uploading the files. The file type filter detects the file type "exe" - "application/octet-stream". Since this file type is not part of the current file type list and the filter mode is set to "stict", the file is rejected and the user is informed about it.
Since User A wants to send the executable file despite the administrator's restrictions, he tries to change the file extension of the file from ".exe" to ".txt" and starts the transfer again. Since the file extension has changed, the file type filter detects the new file type "txt" - "application/octet-stream", which is also not part of the list and rejects the file again.
User A now tries to hide the executable file inside a ZIP file. When the transfer is processed again, the file type "zip" - "application/zip" is detected and the transfer is rejected again, because this file type is also not part of the file type list.
Scenario 2: Tolerant mode + in-depth analysis switched on
The following assumptions are made for this scenario:
- The administrator creates a file type list that contains the file types for PDF, Word and Excel documents, and ZIP files as allowed. The file type for executable .exe files is set to forbidden.
- The list is assigned to all effective policy rules.
- The filter mode is set to "tolerant".
- The in-depth analysis is switched on
- New file type behavior is turned on and notification settings are set to "immediately".
User A wants to send a "forbidden" .exe file to user B. He adds this file and starts the transfer. In this case, the file type filter detects the file type "exe" - "application/octet-stream". Since this file type is set to deny in the used list , the file is rejected and the user is informed about it.
Since User A wants to send the executable file despite the administrator's restrictions, he tries to change the file extension of the file from ".exe" to ".txt" and starts the transfer again. Since the file extension has changed, the file type filter detects the new file type "txt" - "application/octet-stream". However, since the media type "application/octet-stream" is already configured as denied in the file type entry "exe" - "application/octet-stream", the file is also rejected.
User A now tries to hide the executable file inside a ZIP file. When the transfer is processed, the file type "zip" - "application/zip" is detected. This file type is configured as allowed, but the in-depth analysis is active for this file type. Therefore, the container file is analyzed by the file type filter. During the analysis, the embedded file is detected as an EXE file and the transfer is again rejected.
User A now tries to pack the executable file in a 7Zip file instead of a ZIP file. When the transfer is processed again, the file type "7z" - "application/x-7z-compressed" is detected. This file type is not configured in the list and there is no forbidden entry containing the same file extension or media type. Therefore, in this case the file is not filtered and the user is notified that the file was successfully sent.
Since the administrator has configured that new file types should be added to all lists, the file type "7z" - "application/x-7z-compressed" is added as allowed to the file type list and the administrator is immediately notified about the new file type.
File type filter from user's point of view
For the user, the basic use of Cryptshare does not change. Only in case of filtered files by the file type filter, other error messages are issued to the user.
Example: User sends an unauthorized file, in-depth analysis is turned off
In this example, the file type filter has been enabled by the administrator for all transfers. The following assumptions are made:
- The strict filter mode is active.
- In the file type list, only the file type for confidential files is listed as allowed.
The user starts a transfer and attaches only a PDF file. After the successful upload, the file type filter analyzes the uploaded files and filters the PDF file because the associated file type is not part of the list.
The user receives a corresponding notification. Via the expandable message, the user is told that the file type of the sent file is not allowed.
Example: User sends multiple files, in-depth analysis is turned off
In this example, the file type filter has been enabled by the administrator for all transfers. The following assumptions are made:
- The strict filter mode is active.
- In the file type list, the file type for confidential files and the file type pdf - application/pdf are listed as allowed.
The user starts a transfer and attaches a PDF file, as well as a ZIP file. After the successful upload, the file type filter analyzes the uploaded files and filters the ZIP file, because the associated file type is not part of the list.
The user receives a corresponding notification. Via the expandable message, the user is told that the file type of the sent file is not allowed.
Example: User sends a container file, in-depth analysis is enabled
In this example, the file type filter has been enabled by the administrator for all transfers. The following assumptions are made:
- The strict filter mode is active.
- In the file type list, the file type for confidential files, as well as the file types pdf - application/pdf and zip - application/zip are listed as allowed.
The user starts a transfer and attaches a ZIP file containing a pdf and an executable file. After the successful upload, the file type filter analyzes the uploaded files and filters the ZIP file because the executable file type is not part of the list.
The user receives a corresponding notification. Via the expandable message, the user is told that the file type of the embedded file is not allowed. To identify the file, the user is also shown the file path within the ZIP file
