Intel vPro Expert Center Blog

Tweaking the SMS Addon to reduce WMI Load

tal.elgar@intel.com — Fri, 17 Jul 2009 09:35:21 GMT

If you have experienced WMI related issues with the SMS Addon or are worried about potential WMI related issues you might want to read this...

The SMS Addon relies on calls to the WMI service for interacting with SMS and it calls the WMI service more than you might think. For some customers it has been observed that the default frequencies of these calls coupled with the amount of data/entries (such as number of advertisements, number of collections etc.) causes a very high load on the WMI service and a subsequent crash of the service that requires a full reboot of the entire Server (not just the service). Obviously that is not an acceptable situation for a production customer, however there are 8 specific instances where the SMS Addon makes calls to the WMI service which can be tweaked to provide a potential resolution.

You won't see these 8 registry keys in the registry as the SMS Addon uses default values inside the SMS Addon code. You would need to generate these keys yourselves and provide values in order to override the defaults used. The list of these keys and the what they are for are as follows:

All registry keys need to be created in: HKLM\SOFTWARE\Intel\Intel(R) AMT Add-on\GEN\ folder and Dword values need to be entered in minutes. Any value but 0 is legal. There is no disable value and hence 'disabling' is achieved by setting a very high value such as 5 (2,628,000 minutes) or 10 years (5,256,000 minutes).

These is the list of the scheduled WMI related operations:

NewSysScanInterval used to identify new systems in SMS (discovered by SMS discovery methods like AD discovery) – by default runs every 60 minutes – not needed if no systems are managed by SMS Site (such as Central SMS Site).

DeletedSysScanIntervalused to remove information about systems removed from SMS – by default runs every 60 minutes – not needed if no systems are managed by SMS Site (such as Central SMS Site).
SCSSystemScanIntervalused to find new machines in SCS – by default runs every 60 minutes – not needed if no systems are managed by SMS Site (such as Central SMS Site) and also this doesn’t apply if add-on isn’t integrated with SCS.
SystemChangeMembershipScanIntervalused to identify systems membership in groups (for system defense settings) – by default runs every 60 minutes – not needed if no systems are managed by SMS Site (such as Central SMS Site) or if system defense isn't being used.
OffLineSystemScanInterval – used to run commands on machines that were offline (used for system defense and event registration) – by default runs every 5 minutes – not needed if no systems are managed by SMS Site (such as Central SMS Site) or if system defense or event registration aren't being used.
SCSrequestScanInterval – used for tracking requests from add-on to SCS (unprovision, reprovision) – by default runs every 5 minutes – not needed if no systems are managed by SMS Site (such as Central SMS Site) or no un/reprovision commands are run from the add-on; also this doesn’t apply if add-on isn’t integrated with SCS.
UpdatedAdvertisementsScanIntervalused for reading advertisement definitions – by default runs every 2 minutes – not needed if no systems are managed by SMS Site (such as Central SMS Site) or if advertisement wakeup or system defense aren't being used. Runs frequently to pick up any changes to advertisement settings.
AdvertisementChangeScanInterval used for identifying status of systems with system defense settings on advertisements – by default runs every 5 minutes – not needed if no systems are managed by SMS Site (such as Central SMS Site) or that don’t run system defense on advertisement.

Tal

Conficker Worm, Response Times, & Intel vPro Technology

michele.gartner@intel.com — Mon, 13 Apr 2009 20:52:25 GMT

On the eve of April Fools' Day, Terry Cutler blogged about the Conficker worm and Intel vPro technology, posing the question "Can Intel vPro help combat Conficker worm?" In his post, Terry was looking for community feedback on what the IT community is doing to prevent such attacks from occurring. Are you taking advantage of the use cases on your activated vPro boxes? System Defense is your best friend here - it allows you to isolate infected clients from the network. You can also use vPro technology to do things like drastically improve patch saturation - whether the systems are powered on or out of band.

I just uploaded a paper with more information on this topic - please read and see how you can protect your network from attacks from worms like the Conficker.

Conficker Worm, Response Times, & Intel vPro Technology

Secure patches via Intel vPro

terry.c.cutler@intel.com — Wed, 22 Oct 2008 04:23:42 GMT

At ManageFusion Orlando and in The Hague, we did a hands-on lab which combined Intel vPro System Defense capabilities, customized network filter from Altiris, and Altiris Software Delivery to securely update a client(summary available at http://juice.altiris.com/node/5721)

One of the attendees pointed out the following real-world challenge: They are migrating from one security solution to another. This will temporarily expose their client systems to attacks. With the capability to do secure updates – as noted in the lab – they are much better positioned to do to the migration for vPro\AMT enabled systems.

If you’re unsure what 5 minutes “in the open” can do to unsecure client – read the following news article entitled “Malicious ‘botnets’ turn PCs into ‘zombie’ slaves” - http://www.oregonlive.com/business/oregonian/index.ssf?/base/business/1224564910237820.xml&coll=7

Another attendee provided more reference to how they could use this. A classic "chicken/egg" problem - if a client is out of compliance or infected, it must be patched. The patch solution is on the production network, yet corporate policy states systems out of compliance are placed on an isolated or remediated network. So - how do you patch a client to which the production software delivery server cannot connect? Sneaker-net shouldn't be the answer... especially when the target client system is far outside the building you're in.

The key to remember about this use case - the System Defense filters must allow communications on the software delivery network ports. The Altiris Juice article above provides references on this is done in a Symantec\Altiris environment

Intel® vPro™ Security FAQ

agolod01@gmail.com — Fri, 03 Oct 2008 19:34:10 GMT

This page was created to address frequently asked questions (FAQ) related to security of provisioning and configuration of vPro™ machines as well as value added security features introduced with vPro™ technology.

Intel® vPro™ Security FAQ

SDP-1: Permit a Single IP

cmpierce1@gmail.com — Thu, 21 Feb 2008 04:07:17 GMT

This is 1/10 System Defense policy tests I worked on. This test has four systems: three servers & one AMT 3.0 client. I run pings from each server to the vPro and from the vPro (via RDP session) to each server. Then I block all IP except from one server. I lose connectivity including the RDP session but can still manage the system to remove the policy.

What is System Defense & what can it do?

josh.hilliker@intel.com — Fri, 07 Dec 2007 19:04:00 GMT

Craig & I sat down to show a few things on what system defense can do.. Here's a quick intro on Craig and look for more video's on the different uses of SD coming shortly.

If you would like to see if System Defense can do something or not, let Craig know..

here's his first two video's - http://communities.intel.com/docs/DOC-1278

Utilizing Intel vPro AMT System Defense Technology with Altiris Task Server

joel_smith1@symantec.com — Thu, 25 Oct 2007 16:00:00 GMT

Sometimes the methods for dealing with hostile or infected systems on the network are drastic, resulting in lost productivity, time, and energy. In one example the IT staff would physically shut down the user's main network port, sealing off all production systems, test systems, etc, until the hostile machine could be dealt with. Phone calls results, requiring the user to deal personally with the affected system. Now take Intel AMT's System Defense. Remotely quarantine a hostile system and use Altiris to remediate it. System Defense, it puts the power in the hands of the administrator remotely.

Introduction

System Defense (formerly known as Circuit Breaker) allows network filtering at the level of AMT. Systems that have been compromised and are a threat to the network can be remotely quarantined, with certain ports and IP addresses available for remediation. For example the entire network can be filtered out except to the NS, and only those ports required for the Notification Server to remediate the client (install anti-virus, patches, remove harmful software, etc).

Note that testing is vital when using a mechanism that can potentially cut off a system from the network. The ease of remediating compromised systems remotely while quarantining from the main network will remain as long as the filters are properly configured. If not, the system may require a desk-side visit to bring back on the network.

System Defense

System Defense shows as Circuit Breaker in some versions of the Altiris Manageability Toolkit for Intel® vPro Technology. This feature allows a network filter to be placed at the hardware level via AMT. AMT will hijack the operating system's hold on the network connection and apply a secure filter based on a configuration file provided by the administrator.

See the following diagram for a representation of how System Defense (Network filtering) works:

This filter becomes a complete block that disallows any network communication in OR out, save those sources that are configured. Note that the parameters for allowing network communication are those of Sending IP Address and Port. This means that not only to systems have to be explicitly defined to be allowed through, but the ports they are using as well.

Use Cases

The following use cases will find real value with System Defense network filtering:

Virus attack from an infected vPro client - This cuts off the ability of that virus to send packets out on the network
Vulnerable vPro clients without anti-virus - Close off the ability of a virus from getting through to the vulnerable system
Vulnerable vPro clients without critical patches or updates - Quarantine systems, but allow NS to remediate to bring the system up to corporate security standards
Unauthorized Network use - plug a system that is found participating in unauthorized network use, whether it be unauthorized content, gross use of bandwidth for non-approved purposes, etc...
For fun - Drive a fellow administrator crazy by applying and removing filters randomly from his computer (Just kidding, don't try this at home, or at work for that matter)

Task Server Integration

As of Real Time Console Infrastructure release 6.3 the Task Server now has a Task type of Network Filter. This exclusively uses Intel AMT System Defense to apply a comprehensive filter that only allows strict communication to and from the NIC. Because of Task Server's sequencing engine and collection targeting, jobs using this can be setup to do a large number of things, including patching, critical application install such as anti-virus, and other critical computer maintenance items required by the organization.

Task Server Jobs

As a primer for details in this article, see the following article series on Altiris Juice: http://juice.altiris.com/article/2088/utilizing-intel-vpro-amt-technology-with-task-server-introduction.

See the Introduction for more information on jobs. There are two major types of a Network Filtering job:

Apply a System Defense network filter, either the default filter allowing communication to the NS for remediation or a custom filter allowing access to necessary resources
Remove a System Defense network filter to open back up general network communication

See the following screenshot for the option when this Task type is created:

The first radial button allows the application of a filter, either a custom or the default, with the added option of enabling anti-spoofing filter
The second radial button simply applies a PING filter to the target systems
The third and final radial button removes any filters previous applied to the system

Job Targeting

Because of the significance of System Defense and what it does to client computers, I'm going to cover how Task Server Jobs target systems. With a Task Server job you can add individual systems or whole collections of computers. Collections are either manually or dynamically defined and can have few or many systems therein. Multiple systems and collections can be attached to the running of a job, either on demand or by a schedule.

Since System Defense is essentially quarantining vPro Systems, any Task or Job should be tested in a lab environment to ensure workability. If a custom filter is used, the potential to decapitate vPro systems from the network becomes a very real, very severe consequence of improper filters. Take the scenario of having a custom filter that does not allow proper communication back to the Notification Server or another critical resource (like Task Server) in the remediation process. Once the trigger is pulled and the System Defense network filter has been applied, those systems now have insufficient network access to remediate, which may mean that a remote Task to remove the filter is unavailable. IF the job contained half the computers in the environment, the impact is huge.

I say again: Test every filter within every job to ensure everything works properly!

Filter Configuration

Real-Time System Manager allows you to create your own filter configuration files to use with a System Defense Task. In some instances it may be required to open additional ports or destination IPs for full remediation to occur. If you use Package Servers to deliver software you may need to allow communication to these systems.

Edit Network Filters Utility

A utility is provided to create, edit, or otherwise revise any filter file to be used by a System Defense Task. This filter is provided via the Altiris Knowledgebase.

Installation The ENF Utility

See the following article for both the guide in using the utility and to download the utility directly:

https://kb.altiris.com/article.asp?article=34891&p=1

The attached file is a zip. The file included Altiris_ENF_6_2.exe will install the utility on the computer it is executed on. The prerequisites for this utility include:

Windows 2000 Server or Windows 2003 Server
.NET 1.1
Notification Server 6.0 Sp3
At least Real-Time Console Infrastructure 6.2

Using the ENF Utility

Once the installation has run, the Altiris Console can now be used to edit the filters. It's found in the Altiris Console under View > Solutions > Real Time Console Infrastructure > Configuration > and click on ‘Edit Network Filters'. The console provided a spreadsheet of the current filters for the default filter file, as shown:

When you click the Edit pencil icon, a subsequent window will appear. This wizard will walk through editing of the filters. This same wizard is used to add new filters to the list. This wizard is robust and allows minute tuning of what ports are allowed, both for sending and receiving from the NS and from the host AMT computer. The wizard appears as follows:

The default file is called CBFilters.xml and is found at \Program Files\Altiris\RTSM\UIData\. Other files can be created and used in the System Defense Filtering Tasks. It is configurable per Task or Job instance.

NOTE: If you plan on making changes to the default filter file, it is recommended to browsing to the file and making a copy of it. The copy will be a backup to use in case the default file becomes corrupt through editing or for related recovery options.

The best way to know how to open which ports to enable the access you require is to consult the documentation for the application or mechanism you are trying to work with. For example the Task Server uses ports 50120 through 50124, and these ports need to be opened between the Task Server to be used and the client computer.

Conclusion

As previously indicated, make sure you test every system defense task and job you plan to use out in your environment. It's one thing to test against one or two systems where you can manually resolve any unforeseen problems, but if a targeted collection contains many systems and the job or task as an unforeseen issue, this can cut off all these systems from the necessary access to restore network functionality. So test, test, test, and test again before deploying large jobs using System Defense network filtering.

When used properly, this tool enables administrators to remotely deal with vulnerable or infected systems remotely, and stop unauthorized network use. With System Defense enable your administrators to more quickly deal with threats, and remediate in much less time.