Trend Micro Deep Security 9.5 Service Pack 1 Patch 3 Update 3 公開のお知らせ：サポート情報 : トレンドマイクロ
（情報元のブックマーク数
Trend Micro Deep Security 9.5 Service Pack 1 Patch 3 Update 3 リリース。
Trend Micro Deep Security 9.5 Service Pack 1 Patch 3 Update 3 を下記日程にて公開いたします。
■ 公開開始日
2017 年 03 月 14 日 (火)
■ 対象モジュールDeep Security Manager
Deep Security Virtual Appliance
Linux 版 Deep Security Agent
Windows 版 Deep Security Agent
Windows 版 Deep Security Notifier
■ 追加機能/修正内容追加機能や修正内容は付属のReadmeをご覧ください。
※日本語のReadmeは一か月以内に公開いたします。■ 入手方法
本製品の各コンポーネントは最新版ダウンロードページの「統合サーバセキュリティ対策」カテゴリからダウンロードできます。
サポート情報 : トレンドマイクロ
「最新版ダウンロードページ」
2. What's New
========================================================================
2.1 Enhancements
=====================================================================
The following enhancements are included in this release:
Enhancement 1: [DSSEG-510]
After upgrading to Deep Security Agent 9.5.3.7253
using Red Hat Enterprise Linux 6 x86_64 with kernel
version 2.6.32-642.6.1.el6.x86_64, the Intrusion
Prevention and Firewall engines went offline.
Solution 1: The required plugins for this kernel support are
included in this package, which resolves this issue.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enhancement 2: [DSSEG-86]
An enhancement introduced in Deep Security 9.5 SP1
Patch 3, which made the Deep Security Manager capable
of configuring the TLS version in the
configuration.properties file, had an issue where the
Deep Security Relay failed to download software
packages from the Deep Security Manager when it was
configured to use TLSv1.2 only.
Solution 2: This issue has been fixed.
Note:
When Deep Security Manager is forced to use TLS 1.2
only, communication between the Deep Security Manager
and NSX will be broken because when NSX connects back
to the Deep Security Manager over port 4119, it can
only use TLS 1.0. This is a current NSX Manager
limitation.
Similarly, in a non-NSX environment, where Deep
Security Filter Driver is deployed, a minimum version
of ESXi 5.5 is required to make TLS 1.2 work properly.
Limitation:
Windows Powershell deployment scripts generated by the
Deep Security Manager fail during execution. This
happens during an attempt to download the Agent
installer from the Deep Security Manager. This is not
the case with Linux Platforms.
Workaround:
To make deployment scripts work, you must add the
following line in the script manually:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12;
Requirement:
To make these deployment scripts work, Windows
platforms must run Powershell version 4.0 or later.
Windows 8 or later is equipped with Powershell 4.0.
You can upgrade Windows 7 and Windows 2008 R2 from
Powershell 2.0 to 4.0. Using the TLS 1.2 option and
using deployment scripts with Powershell is not
supported on Windows platforms earlier than Windows 7.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2.2 Resolved Known Issues
=====================================================================
This release resolves the following issues:
Issue 1: [DSSEG-754]
Linux systems would sometimes hang when the Deep
Security Agent's kernel module, dsa_filter, was
getting the driver's information from certain network
interfaces.
Solution 1: The issue is fixed in this release.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Issue 2: [DSSEG-750]
When many application types were assigned to monitor
the same port, there was a chance that some
connections were not monitored due to an internal
defect.
Solution 2: This issue is fixed in this release.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Issue 3: [DSSEG-738]
The DSRU16-032 rule introduced a new rule to monitor
HTTP traffic. When the rule was applied and multiple
rules monitored HTTP traffic, one particular rule
order could mistakenly trigger the 'duplicate content
len' event.
Solution 3: This issue is fixed in this release.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Issue 4: [DSSEG-582]
The Deep Security Agent can handle a maximum of 32
network interfaces. When the Agent was installed on a
Red Hat Linux 6x64 computer running KVM (Kernel
Virtual Machine), traffic from a larger interface was
dropped by the Filter Driver (dsa_filter).
Solution 4: This fix enables the Deep Security Agent to bypass
traffic created through tap interfaces, incuding
traffic generated by the KVM. This results in no
traffic being dropped.
Note:
1- This fix is applicable to RHEL 6x64 machines
running KVM hypervisor only.
2- Bypassing the network traffic through tap
interfaces does not create a security concern because
the traffic is inspected based on the policy applied
at the hypervisor level.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Issue 5: [DSSEG-564]
The Deep Security Virtual Appliance (DSVA) restarted
abnormally and crashed the dsplash.pl file.
Solution 5: A script has been modified to avoid this situation in
the future.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Issue 6: [DSSEG-500]
The 9.5 version of the Deep Security Virtual
Appliance uses a system "curl" tool to initialize the
TLS connection with the Deep Security Relay to save
or restore status files during vMotion. The curl tool
was an older version that did not have the ability to
turn off the TLS "CN Verification". After upgrading
to Deep Security Agent 9.5, the OpenSSL and Curl
library are upgraded and by default, the "CN
verification" is turned on and causes this error:
"certificate subject name 'Deep Security Relay' does
not match target host name" when the virtual
appliance saves or restores status during vMotion.
Solution 6: Install a new version of curl to the DSVA
"/opt/ds_agent" folder and use it to disable "CN
Check" when the Deep Security Virtual Appliance saves
or restores status during vMotion.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Issue 7: [DSSEG-497]
The guest VMs' network connectivity was broken and
could not recover until the Deep Security Virtual
Appliance was restarted.
Solution 7: The issue was caused by an inconsistent state in the
vmxnet3 driver. To address this issue, vmxnet3.ko
will restore the inconsistent state when it is
detected.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Issue 8: [DSSEG-455]
OpenSSL minor version upgrade to patch low impact
vulnerabilities like: CVE-2016-6305, CVE-2016-2182
and CVE-2016-6304
Solution 8: OpenSSL 1.0.2h is now upgraded to 1.0.2j
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Issue 9: [DSSEG-428]
When ds_am started, the ds_am process caused a
segmentation fault that created many core dump files
repeatedly.
Solution 9: This issue is fixed in this release.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Issue 10: [DSSEG-384]
The Deep Security Agent on Red Hat Linux 7 caused a
kernel panic due to the redirfs kernel module used
for file-system hooking.
Solution 10: This issue is fixed in this release.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Issue 11: [DSSEG-371]
On SuSE Linux, the ds_agent service status checking
resulted in incorrect information.
Solution 11: This issue is fixed in this release.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Issue 12: [DSSEG-334]
When an Anti-malware realtime scan was enabled in the
Deep Security Agent, there was an unacceptable
increase in I/O latency of NFS volumes.
Solution 12: This issue has been fixed by unhooking the redirfs
from NFS volumes.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Issue 13: [DSSEG-283]
The ds_agent process crashed when a Log Inspection
task started to run while the Log Inspection service
was asked to restart from another thread.
Solution 13: Code now ensures that the Log Inspection service
restarts after all tasks are finished.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Issue 14: [DSSEG-261]
The syslog would receive a flood of “Assertion
Failed: dev” messages because the Deep Security
ds_filter driver supported a maximum of only 32
network devices. If this maximum was reached, such as
with Docker Containers, the array used to store
network devices (lin_devices) would become full and
new devices could not be added.
Solution 14: This issue is fixed in this release.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Issue 15: [DSSEG-221]
In certain situations, if an Intrusion Prevention
event was already sent to the Deep Security Manager,
then restarting the Deep Security Agent service would
send the event again, causing duplicate events to
appear in the Deep Security Manager console, on the
Intrusion Prevention events tab.
Solution 15: This issue is fixed in this release.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Issue 16: [DSSEG-214]
By default, the maximum number of TCP connections for
the Deep Security Agent is set to 1000. If the
maximum was reached, the ds_agent.log file was
flooded with error messages related to maximum
connections reached. This caused the logs to fill
very quickly and sometimes filled up the disk space.
Solution 16: This fix changes the logging level from "Error" to
"Warning" and events are now logged less frequently.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Issue 17: [DSSEG-204]
When real-time Anti-malware scanning was enabled on a
Linux system (Red Hat, SUSE) and then the "ls"
command was executed in a folder where hundreds of
thousands of files resided, it took a long time to
complete the scan and it seemed as if the machine was
hung.
Solution 17: This issue is fixed in this release.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Issue 18: [DSSEG-203]
When Anti-Malware was enabled on a Linux system
(RedHat, SUSE), the system would crash due to a
problem with the GSCH driver.
Solution 18: This issue is fixed in this release.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Issue 19: [DSSEG-201]
A kernel panic would sometime happen if there was no
extension in the TLS Client Hello Packets received by
the Deep Security Filter Driver.
Solution 19: This issue is fixed in this release.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~