‘Another day another dollar’…. no no that’s not quite right…
‘Another day another Deep Security issue.’
Next up is Deep Security and UNC\SMB Scanning. This isn’t exactly Deep Security’s fault as this is another limitation of the vShield EPSEC driver.
Executables that are accessed via a SMB share will loop and need to be manually killed. This is a known limitation of the EPSEC driver as disccused in Trend Micro KB1059280.
In our case one of our applications was launching an executable from a UNC path which was crashing. We couldn’t figure out why but unmanaging the virtual machine fixed the problem.
It is relatively easy to fix this problem, but it does leave you exposed.
The EPSEC driver does not support exclusions of a particular server name, i.e. \\servername, nor can you exclude a directory on the server nor can you exclude a specific file even if you know the name. The only way to fix this problem is to exclude all UNC paths\SMB scanning, by updating your security policy and adding the exclusion ‘\\’ to your Directory exclusion list.
Even unticking ‘Scan Network Drives’ from within Trend has no effect. This has been raised as an incident and I am yet to hear back from Trend Micro.
I have been assured by VMware this will be resolved in vShield 5.1 released in Q4 2012.
Thanks to http://www.joulupukki.nl/wordpress/?p=523 for alerting me to this issue.
VMware made a pre release of the new vShield Endpoint Driver (126.96.36.199 build-813867) available last week to customers who are experiencing issues with their current vShield Driver. This will be released in Q4 but if you are using an anti malware product in your virtual environment that relies on vShield Endpoint Driver I would contact VMware to get the patch.
This hotfix needs to be applied on top of vShield Endpoint Driver build 652273 which is available with the VMware tools included with ESXi 5 Express Patch 3 (build 702118).
In the words of VMware this fixes two main issues: performance issues with network files and sharing violation issues.
1. Sharing violations – It was discovered that, while you had the thin agent installed and real-time AV scanning running, if you opened a file on a network share a few times in quick succession, the 3rd or 4th attempt could result in the file being locked. This was due to the lack of caching for network files, which is the recommend AV practice, but caused this locking
2. Performance issues – This was to due to the general overhead when our thin agent called some MS filter methods.
I also found that this version fixes a BSOD issue with vsepflt.sys. More about that in my next post.
1. Launch msinfo32.exe on server
2. Open Software Environment -> System Drivers
3. Scroll down and make sure vFileFilter exists and it is running