- CheckMates
- :
- Products
- :
- Quantum
- :
- Threat Prevention
- :
- Re: Anti-Virus Blade - Strict hold is not possible...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Anti-Virus Blade - Strict hold is not possible failure - Write to other side occured
I am getting a strange error from one of our servers that is trying to upload information to a remote site.
The file is getting blocked by the Anti-Virus Blade with the following error "Strict hold is not possible failure - Write to other side occured"
I tried putting in an exception for the antivirus blade but its not taking effect.
The gateways are running R80.30 T107 and we have just started to experience this issue as it was working previously.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Strict Hold is a new feature in R80.30 related to Threat Extraction.
If you're not using Threat Extraction on the gateway, you can disable this feature.
If you are using Threat Extraction, there are a few TAC cases that suggest that the upgrade process from earlier releases did not add the necessary configuration to $FWDIR/conf/malware_config
You can confirm this by:
- Checking if Hold Mode is enabled in SmartDashboard: Manage and Settings > Threat Prevention > General. If you're not using Threat Extraction, disabling this feature in SmartDashboard and installing policy should be sufficient.
- Seeing if there is a section for strict_hold_configuration in $FWDIR/conf/malware_config on the gateway and it has a setting for strict_hold_enable. If it does not, you need to add the necessary configuration.
In this case, add the following lines to $FWDIR/conf/malware_config on every affected gateway.
Note you can adjust the configuration of these lines as necessary (e.g. if you want Strict Hold to be enabled, set the parameter to 1)
[strict_hold_configuration]
strict_hold_enable=0
enable_on_background_mode=0
min_size_to_upload=0
max_size_to_upload=100000000# when tex_over_te enabled - perform sending TEX extracted file to client without waiting for TE full emulation verdict.
tex_over_te=0
flexible_hold_precent_to_send=50
flexible_hold_total_time_to_trickle_in_minutes=4
[strict_hold_fail_open_config]
strict_hold_fail_open_flag=1
url_entry_timeout=30
url_key_type=1
compare_second_try_md5=0
Once you've made this change, perform a policy install to the relevant gateways for these changes to take effect.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Strict Hold is a new feature in R80.30 related to Threat Extraction.
If you're not using Threat Extraction on the gateway, you can disable this feature.
If you are using Threat Extraction, there are a few TAC cases that suggest that the upgrade process from earlier releases did not add the necessary configuration to $FWDIR/conf/malware_config
You can confirm this by:
- Checking if Hold Mode is enabled in SmartDashboard: Manage and Settings > Threat Prevention > General. If you're not using Threat Extraction, disabling this feature in SmartDashboard and installing policy should be sufficient.
- Seeing if there is a section for strict_hold_configuration in $FWDIR/conf/malware_config on the gateway and it has a setting for strict_hold_enable. If it does not, you need to add the necessary configuration.
In this case, add the following lines to $FWDIR/conf/malware_config on every affected gateway.
Note you can adjust the configuration of these lines as necessary (e.g. if you want Strict Hold to be enabled, set the parameter to 1)
[strict_hold_configuration]
strict_hold_enable=0
enable_on_background_mode=0
min_size_to_upload=0
max_size_to_upload=100000000# when tex_over_te enabled - perform sending TEX extracted file to client without waiting for TE full emulation verdict.
tex_over_te=0
flexible_hold_precent_to_send=50
flexible_hold_total_time_to_trickle_in_minutes=4
[strict_hold_fail_open_config]
strict_hold_fail_open_flag=1
url_entry_timeout=30
url_key_type=1
compare_second_try_md5=0
Once you've made this change, perform a policy install to the relevant gateways for these changes to take effect.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey Paul
We are aware of this issue.
It is relevant in HTTP 100 continue scenario.
The issue was resolved in R80.40 and planned to be integrated to R80.30 JHF.
** Editing - we've found cases where the issue is relevant to R80.40 and working on adding to jumbo as well **
Thanks
Shiran
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Shiran,
is there any workaround short of disabling the blade?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you are using Threat Extraction over HTTP - Strict hold is a must.
If not, you can disable strict hold feature (use legacy hold mechanism)
Go to $FWDIR/conf/malware_config
Search for strict_hold_enable parameter.
Change it from 1 to 0.
(strict_hold_enable=0)
Install Threat policy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Has this fix been added to R80.30 JHF?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The fix is not yet in R80.30 Jumbo. R&D are working on a fix. We will update once it will be ready
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Shiran,
that's not true! - We are currently on R80.40 HF 78 and rolled into this issue.
We had to disable the strict_policy in the config file!
So hopefully there will be a fix soon.
Thanks and regards,
Christian
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey Christian
I have sent you a private message to further understand the scenario.
Thanks,
Shiran
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Fix was released as part of Jumbo R80.40, take 91
Check out our sk165456 :
PRJ-19579, PRJ-16924 |
Anti-Virus | In rare scenarios, after downloading files, Anti-Virus prevent logs appear with "Strict hold is not possible failure - Write to other side occurred" error message. |
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I saw PRJ-16924 was solved in the latest R80.30 take (226) but we still have a similar issue. PRJ-19579 is not mentioned in the list (sk153152). Does it mean it is not yet solved completely on R80.30? So far putting strict_hold_enable=0 seems to work (more testing needed as we didn't have the issue always).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Clean install and running R80.40 with installed take 91 with same problem. This is still an on-going problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for your comments, Please open a TAC ticket for this issue and we will check it with the relevant owner.
