July 2008 - Posts
Today I ran into an issue with a client that seemed unable to download the latest CounterSpy Enterprise ThreatDB.
Normally invoking a quick or full scan forces a download of the local ThreatDB -- either from the local server or from the Internet as a fallback if the client is so configured.
In this particular case, the client was not updating the DB, which was causing problems with network connectivity due to certain safeguards we have in place.
I've found that the best solution in these types of cases is to stop the CounterSpyAgent service and delete SBTS.dat and SBTEDef.idx. These are the ThreatDB files themselves and when the CounterSpyAgent service is then restarted, it will re-download a full DB from the server/Internet as the case may be.
Recently I deployed McAfee Agent 4.0 to one of our company's ePO 4 Server and Windows workstation clients after a bit of testing with relative success.
For those interested, the master list of support articles for the 4.0 Agent is located here:
https://knowledge.mcafee.com/SupportSite/dynamickc.do?externalId=615002&sliceId=SAL_Public&command=show&forward=nonthreadedKC&kcId=615002
Release notes are available here:
https://knowledge.mcafee.com/SupportSite/dynamickc.do?sliceId=SAL_Public&command=show&forward=nonthreadedKC&externalId=615005
Major changes to the Windows agent include the ability to detect laptops and x64 OS's and query/tag based on those properties (which also means you can now leverage things like only deploying PreScan to Win32 clients, or only applying HIPS to laptops without using a 3rd party deployment tool), changes to the sitelist.xml format that allow for DNS and NetBIOS-based entries instead of solely IP-based, as well as changes to the installer format.
Since the new McAfee Agent 4.0 enters itself in Add/Remove Programs, I created a WQL query to create a collection that would identify those that did not have the McAfee Agent listed in ARP. In the future, I'll need to change this to query on version but currently this is how I'm identifying clients that need the upgrade:
select SMS_R_System.ResourceID,SMS_R_System.ResourceType,SMS_R_System.Name,SMS_R_System.SMSUniqueIdentifier,SMS_R_System.ResourceDomainORWorkgroup,SMS_R_System.Client from SMS_R_System where Name not in (select SMS_R_System.Name from SMS_R_System inner join SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName = "McAfee Agent")
This WQL statement will definitely need to be revised in the near future to account for version variations. When I make the adjustments, I'll post them here.
Incidentally, McAfee Windows Agent 4.0 Hotfix 1 has been released. (FYI The build version for this particular hotfix is 4.0.0.1318 vs. 4.0.0.1180 for the shipping version)
You'll need to open a case with PrimeSupport in order to receive it however as it is not yet available via the PrimeSupport portal. More details here:
https://knowledge.mcafee.com/article/200/616270_f.SAL_Public.html
Resolved issues:
- Issue: The McAfee Agent's ability to perform updates is blocked when the name of the installation or data folders includes an extended ASCII character. (Reference: 404111)
Resolution:The McAfee Agent's ability to update is no longer blocked if the installation or data folder names include an extended ASCII character. - Issue: The McAfee Agent process "RunPullTask" would run, but it wouldn't copy SiteStat.xml to the specified mirror location. (Reference: 409637)
Resolution:The McAfee Agent process "RunPullTask" now creates a SiteStat.xml file in the appropriate mirror location. - Issue:When a managed product's plug-in required a reboot, the user was prompted, but the computer rebooted even when the user selected No. (Reference: 410573)
Resolution:The McAfee Agent now responds correctly based on the user's selection.
Impressions of McAfee Agent 4.0:
Although I can't say installation went off flawlessly (more on that in a moment), the installation was completely transparent to the end user and the new x64 and IsLaptop properties seem to be detected correctly on clients, as I have tags automatically applied based on these criteria and they began functioning immediately. I cannot speak for the changes to the sitelist.xml as we're not basing our repositories on DNS or NetBIOS, I can only say that the clients are still updating properly post-installation.
Gripes about installation:
Just like many McAfee updates before, despite the fact that I alter my deployment and update tasks accordingly, often days and/or weeks before checking an update package into the server, I still find that the update will be applied to numerous machines where the task explicitly states not to update that particular component. In this case, checking in Agent 4 resulted in it being deployed to numerous machines where the deployment task should have prevented its installation. One of the advantages of ePolicy Orchestrator 4 is the ability to view task inheritance and review that no task inheritance is broken (or at least only those you want broken), and I verified this days before checking in the package. In an environment such as ours where due to compliance issues we tightly regulate the deployment of *ANY* software update, this is unacceptable.
It isn't as if I haven't observed this many times in the past in multiple environments, but it is disappointing to see that it is still an issue. I don't know if this is a remnant of the glitches I've observed in 3.6, but I'm hopeful that the 4.0 agent may address this glaring flaw moving forward. I guess I'll find out when I begin applying McAfee VirusScan 8.5 Patch 6.1...
I've been working on a few things in and out of the office which I will blog about soon, but mainly, things have been pretty much busy yet uneventful and I haven't had much to say here. All that will change soon, as I have a few new projects about to begin...
But before that, expect there will be very few updates in the next week, as I will be basking in the Bermuda sun starting Wednesday afternoon :)
Details here:
https://knowledge.mcafee.com/SupportSite/dynamickc.do?externalId=616311&sliceId=SAL_Public&command=show&forward=nonthreadedKC&kcId=616311
Improvements:
1. The on-demand scanner has been updated to better use the System Utilization setting throughout the entire scanning process.
Refer to McAfee Support Knowledgebase article 9197288 for further information.
2. This Patch contains a new Buffer Overflow and Access Protection DAT (version 378) which adds an Access Protection category for Virtual Machine Protection. These rules provide access protection functionality for virtual machines.
NOTE:
In order to manage the new Virtual Machine Protection category with ePolicy Orchestrator 3.x or Protection Pilot, you will need to use the latest NAP file, included in this Patch package, or VirusScan 8.5i Repost Patch 5.
For ePolicy Orchestrator 4.x users, the Extension update also contains the updated rule file. The updated Extension package is available on the web product download area under the Patches category.
PATCH 6.1 RESOLVED ISSUES
1. ISSUE:
An issue can occur when the 5300 engine is installed prior to installing VirusScan 8.5i Patch 6. The scanner engine files are partially overwritten with the previous 5200 version that is stored in the MSI cache. This mismatch causes the scanner engine to fail to initialize.
RESOLUTION:
The Patch installation package has been updated to correct this issue, and does not overwrite the engine files.
PATCH 6 RESOLVED ISSUES
1. ISSUE:
The VirusScan Enterprise management plug-in writes all settings to the registry on every policy enforcement. McShield service monitors the registry and reloads whenever the settings are written, generating frequent pause events in the Windows System log.
RESOLUTION:
The VirusScan Enterprise management plug-in has been updated to only write to the registry if it sees that it is different from the current policy. This will prevent McShield from generating events on policy enforcement, unless that policy has changed.
This is an addendum to the original solution in Patch 5, where the fix did not work when the preferred language was set to something other then automatic.
2. ISSUE:
A compatibility issue has been seen with VirusScan’s port blocking feature, and Veritas backup applications. This was causing the backup software services to stop running.
RESOLUTION:
The VirusScan Anti-Virus Mini-Firewall Driver has been updated to correct the compatibility issue.
3. ISSUE:
A race condition in the On-Access Scanner service can cause high CPU utilization with high performance systems.
RESOLUTION:
The On-Access Scanner service has been updated to remedy multi-threading synchronization issues and remove occurrences of runaway threads.
4. ISSUE:
The On-Access Scanner service sometimes crashes during a system shutdown or during installation of a Patch/HotFix.
RESOLUTION:
The On-Access Scanner service has been repaired to correct a race condition in which a critical-section synchronization object is deleted before another thread has entered.
5. ISSUE:
A deadlock could occur on high end servers caused by a race condition in VirusScan’s link driver.
RESOLUTION:
The link driver has been changed to properly handle the release of system objects, while holding a lock on resources.
6. ISSUE:
Port blocking fails on Microsoft Windows Vista Service Pack 1.
RESOLUTION:
The McAfee Driver Installer has been update to handle the changes in network stack load order.
7. ISSUE:
The On-Demand Scanner system utilization changes that were put in patch 5 changed the memory scanning function. This caused the process
scanning to only scan the first process ID.
RESOLUTION:
The change has been reversed so that all processes are scanning irrespective of process ID.
8. ISSUE:
When applied to a client installation that was customized by McAfee Installation Designer (MID), the patch installer deletes the MidFileTime registry value. This caused MID .CAB files to be re-applied to the system.
RESOLUTION:
The patch installer has been updated to no longer delete the MidFileTime registry value.
9. ISSUE:
A newly created user defined Unwanted Program Policy, does not take affect immediately if the file has been scanned by the On-Access Scanner before the change occurred.
RESOLUTION:
The On-Access Scanner service has been updated to properly recognize changes to the user defined detections and clear the cache of files that have already been scanned so that the new settings take effect immediately.
10. ISSUE:
A trust relationship exists in McAfee drivers that can be leveraged by McAfee processes to avoid triggering access protection rules and other compatibility symptoms. When the link driver was updated to newer releases this trust relationship was lost until a reboot occurred.
RESOLUTION:
The link driver has been modified to better handle the process of future upgrades to itself without the need for a reboot.
After reading this post on the SANS ISC weblog, I thought I would provide the WQL I'm currently using in SMS to deploy the Adobe Acrobat and Reader 8.1.2 security update.
The following WQL will query Add/Remove Programs on clients and identify those who have Acrobat or Reader 8.1.2 but not the Security Update 1. Hope someone finds this useful:
select SMS_R_System.ResourceID,SMS_R_System.ResourceType,SMS_R_System.Name,SMS_R_System.SMSUniqueIdentifier,SMS_R_System.ResourceDomainORWorkgroup,SMS_R_System.Client from SMS_R_System inner join SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId where SMS_R_System.Name not in (select SMS_R_System.Name from SMS_R_System inner join SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName = "Adobe Acrobat and Reader 8.1.2 Security Update 1 (KB403742)" ) and SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName in ( "Adobe Acrobat 8.1.2 Professional", "Adobe Acrobat 8.1.2 Standard", "Adobe Reader 8.1.2" )
Despite my HIPS exclusion to completely ignore port scans, I still was bombarded with alerts for a TCP port scan.
More interesting still, the System event viewer on many Windows clients was showing the following error once a day:
Event Type: Error
Event Source: TermDD
Event Category: None
Event ID: 50
Description:
The RDP protocol component X.224 detected an error in the protocol stream and has disconnected the client.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
So, yesterday I disabled "Device details detection" in the policy for RSD sensors. Today, no more alerts and no more errors. Too bad I have to turn this off, but it seems to be more trouble than it's worth.
I installed Rogue System Detection 2.0 for ePolicy Orchestrator 4.0 yesterday. Setup completed without a hitch, and I didn't even need to install it separately as an extension like most of their products.
It's not much different than the 1.0 version. The sensor deployment seems a bit more reliable, and the new web frontend is definitely slick. I spent the better part of the day methodically identifying and excluding networking devices and the like, and I'm pleased to say that there are a negligible number of malfunctioning McAfee agents in our environment. Deploying an agent package cleared most of the issues up and I'm addressing the few remain individually.
The one thing I've noticed is that HIPS is flagging a Port Scan threat from the RSD sensor as it interrogates the client. I've tried writing an exception for HIPS to disregard alerts for Port Scans against the IP's in question, but it doesn't seem to work. Even excluding the signature altogether doesn't seem to do it. Actually, it doesn't appear that the exclusions work all that well in HIPS 7 period... 6.x worked far more reliably and would say it was definitely easier to manage.
I am curious whether disabling "Device details detection" in the Rogue System Detection policy would resolve this, or whether it just does an aggressive nmap style scan on detected systems altogether... in which case changing this would likely accomplish nothing. Either way, I don't think it's the preferred method to take, as I'll have a lot less data available for identifying IP's that don't report hostnames etc.
I suppose I'll wait another day to see if client policy catches up and the HIPS clients stop sending me these darn alerts. More to follow.
Monday I attempted to update our ePolicy Orchestrator server from 4.0 Patch 1 to 4.0 Patch 2.
Our ePO 4.0 Server resides as a guest on a VMware server with a remote SQL backend. This is dissimilar from our old ePO 3.6.1 Server, which had its own instance of SQL 2000 locally. Also, this time we are (well, were) using Windows authentication instead of SQL authentication, which we had in the past.
Patching the ePO Server has generally been a painless process, but this particular patch was over 150MB, so I had a sinking feeling that this wouldn't be one of those times...
Turns out, I was right. I got partway through the install - everything's looking good... then BAM... out of the blue:
Setup has encountered the error:
FAILURE: In LaunchAppAndWait while trying to run the following program:
""
And, yes, those are empty quotes. Weird, I know.
A little digging in C:\Docume~1\username\Local Settings\Temp\NAILogs\EPO400-Patch-MSI.LOG shows a bit more to the error:
FAILURE: In LaunchAppAndWait while trying to run the following program:
"C:\PROGRA~1\McAfee\EPOLIC~1\jre\bin\java.exe" ... blah ...
Some Googling gave a bit more information in the form of a McAfee technote, appropriately titled "ePO 4.0 Patch 2 fails to install on a VMWare image containing ePO 4.0 and SQL Server 2005 / SQL 2005 Express" and located here:
https://knowledge.mcafee.com/article/60/615839_f.SAL_Public.html
The issue apparently results from the use of Windows authentication for SQL 2005, specifically when used on a VMware server. In order to complete the patch, ePO must be configured to use an account with dbowner rights (note that it is *not* required to use sa despite the KB using that as an example).
The following steps will resolve the issue:
- Log in to your ePO Server at http://servername:port/core/config
- Change the user name to an appropriate SQL ID
- Set the password accordingly
- Remove the domain listed next to User domain
- Click Test Connection
- If the test completes successfully, click Apply
- Restart the "McAfee ePolicy Orchestrator 4.0.0 Application Server" service
- Reapply the patch
- Verify that the patch applied and all extensions were checked in successfully via the logfiles as per the patch 2 readme file
- Verify that dashboards, etc function as intended.
At this point you should be able to reverse the steps above to return ePO Server to use Windows authentication if you so desire.
It's been over a year since I posted here. I've been keeping myself busy at work with various projects... and many family obligations and other circumstances dictated that my blogging needed to take a backseat for the time being.
So what have I been up to tech-wise? To name a few of the larger endeavors:
- I've upgraded our SMS heirarchy to SP3 and integrated the Asset Intelligence feature as well as the catalog update.
- Installed Ron's Web Remote Tools with Sherry's tweaks, much to the happiness of both our technicians and my management. If either of you read this, kudos to you both for providing these to the community. It's certainly made my life easier :)
- I've replaced our production ePolicy Orchestrator 3.6.x environment with a VMware host running ePolicy Orchestrator 4.0 with Patch 1. All VirusScan clients were upgraded to 8.5i with the 5200 engine. All McAfee HIPS clients were upgraded to 7.0 with Patch 1. More gripes about McAfee to follow in coming weeks, I'm sure. There's just not enough room here to post them all :)
- I've deployed a series of CounterSpy Enterprise 2.0 "servers" (I use this term loosely) in our home office and branch offices throughout the globe and deployed a series of CounterSpy Enterprise agent versions to all clients in those offices. CounterSpy was later upgraded to 3.0 for the servers.
As well as many other, far-less interesting things like application deployments, which I won't get in to here.
Lately I've been working in a few "new-to-me" areas: the Microsoft Deployment Toolkit (and WDS), SCCM 2007, x64 Operating Systems, and of course Vista - all of which will be deployed as the standard within my organization in coming months.
I've recently been approved to begin a side-by-side deployment of SCCM SP1 and migrate all our existing SMS clients to the new infrastructure. Following that, I anticipate going to SCCM Native Mode, and leveraging the OSD aspects of MDT and SCCM to standardize on a single image, phasing out the multiple Ghost image approach that is currently used by our technicians. I hope to utilize this blog in part to document my process and any "lessons learned" along the way.
With that said, I'll close this entry. Stay tuned, more to follow!