Securing Configuration Manager Communications
Many of the attacks we
see today are network-based attacks. ConfigMgr sites, site systems, and
clients communicate across network links and are potentially susceptible
to the following types of attacks:
Misdirection attacks—
Where a client or site system is provided with the wrong name or
Internet Protocol (IP) address for the partner with which it needs to
communicate. To avoid misdirection attacks, you must secure service
advertisement and name resolution services.
Spoofing attacks—
Where a rogue system impersonates the actual system with which a client
or site system needs to communicate. To defeat spoofing attacks, all
communications must be properly authenticated.
Eavesdropping or sniffer-based attacks—
Where an attacker intercepts network communications, gaining access to
confidential information. Data encryption is the primary defense against
breach of confidential communications.
Man-in-the-middle (MITM) attacks—
Attacks in which an attacker steals, alters, or interrupts
communications by routing data through an intermediate node that is
under the attacker’s control. You can often defeat MITM attacks by using
mutual authentication. Digitally signing files can help you detect
alterations due to MITM attacks.
Denial of service attacks— When
an attacker uses large amounts of data or malformed data packets to
crash systems or clog communication links. A resilient network
infrastructure and fault tolerant service delivery design are your best
defenses against DoS attacks.
Microsoft
provides several security features to protect the confidentiality,
integrity, and availability of ConfigMgr communications. The next
sections consider how you can use these features to secure
communications between ConfigMgr clients and their site, and
communications between ConfigMgr sites and site systems.
Caution: Don’t Let Attackers Use Encryption to Bypass Other Security Controls
Cryptographic
controls such as encryption and digital signatures are among the most
important security mechanisms you can use to protect the confidentiality
and integrity of data. Encryption can be something of a double-edged
sword, however, because many other security controls do not work on
encrypted data. For example, antivirus programs are typically unable to
scan encrypted files. Similarly, network Intrusion Detection Systems
(IDS) or Intrusion Prevention Systems (IPS) cannot inspect encrypted
packets for attack signatures. You should consider procedures to make
sure any files and packets that bypass one control are inspected by
another, such as quarantining inbound encrypted files until they can be
decrypted and scanned, or using a host-based IDS or IPS at each endpoint
of an encrypted tunnel.
Securing Client to Server Communications
The integrity of
the policy and content your clients receive is the paramount
consideration when considering client-to-server communications. An
attacker who can direct client policy requests to a rogue management
point or tamper with client policy can instruct the ConfigMgr agent to
execute instructions of the attacker’s choosing. Similarly, an attacker
who can cause clients to use forged or altered content such as software
packages or OS images could gain control of client systems. Data sent by
the clients to the servers is generally less critical than policy and
content received by the clients; however, you should consider the
importance of the confidentiality and integrity of inventory and
discovery data and status messages in your environment.
ConfigMgr native
mode provides much stronger security for client-to-server communications
than mixed mode. Native mode uses PKI certificates to provide mutual
authentication and Secure Sockets Layer (SSL) encryption for most
communication between clients and servers. Mutual authentication ensures
that clients and servers are communicating with the correct systems and
protects against man-in-the-middle attacks. If your site provides
support for mobile device management in mixed mode, distribution points
must allow anonymous access. The anonymous access allows unauthenticated
clients access to ConfigMgr content. Even in native mode, there is no
encryption or authentication of Server Message Block (SMB)
communications. You should therefore configure all distribution points
to use BITS to avoid having clients download content using SMB. As
branch distribution points and server shares use SMB for all content
access, they are less secure than standard BITS-enabled distribution
points.
ConfigMgr
uses a signing certificate to protect the integrity of policy downloads.
In mixed mode, the management point signs client policy. In native
mode, the site server signs the policy. Management points are generally
less secure systems than the site server is because they must accept
connections from clients and run IIS. Keep in mind that if you enable
the HTTP communication for roaming and site assignment site property,
clients will communicate with management points and distribution points
without encryption or mutual authentication when they roam at mixed mode
sites. For maximum security, enable Certificate Revocation
List (CRL) checking. CRL checking causes the client to check a list of
revoked certificates when communicating with site systems. Note that CRL
checking requires that your CRL be available at all times and
introduces a significant delay in client to server communications. You
can enable CRL checking as either as a site property or a client setup
property, as described in http://technet.microsoft.com/en-us/library/bb680540.aspx.
Native mode requirements include a PKI infrastructure and exclude any support for SMS 2003 clients.If your site
meets all native mode prerequisites, you still need to plan for native
mode and deploy all required certificates. Microsoft provides a workflow
for migrating to native mode at http://technet.microsoft.com/en-us/library/bb680838.aspx.
If your sites meet the native mode requirements, you should strongly
consider making the investment of migrating to native mode for optimal
security, whether or not you require native mode features, such as IBCM.
Keep in mind that you can easily revert to mixed mode if you encounter
problems after enabling native mode.
If you are not ready to
enable native mode on your sites, there are several steps to take to
secure client-to-server communications within mixed mode sites:
- If
possible, upgrade all clients to ConfigMgr 2007 and enable the This site
contains only ConfigMgr 2007 clients check box in the site properties.
This setting limits downloading of policy containing sensitive
information only to approved clients.
- Do not
automatically approve all clients. Clients can be used to attack the
site, for example by sending excessive or malformed inventory as a DoS
attack. Clients can also retrieve policy from the site, which might
expose sensitive information about your site’s configuration and
operations. The option to manually approve all clients gives you the
most control but requires substantial administrative overhead and is,
therefore, not suitable for most installations. The automatically
approve clients from trusted domains is the preferred option in most
situations.
- In mixed mode, client inventory is signed
but not encrypted by default. To provide confidential uploading of
inventory data, enable the Encrypt data before sending to Management
Point option in the site Properties.
The client agent
downloads policy from its management point and executes instructions
specified in the policy. Control of the policy is, therefore, control of
the client. This makes it essential that clients verify that they are
communicating with the correct management point. All communications from
the management point to the client are signed using the management
point’s self-signed certificate. Before the client can trust the
management point’s
certificate, the client must have a list of management points it should
trust and a copy of the certificate signed by a trusted authority. If
you have extended the Active Directory schema and enabled AD publishing
of site information, clients in the same AD forest with the site server
can retrieve a list of management points from a global catalog server.If the client cannot retrieve
management point information from AD, the client can use Windows
Internet Name Service (WINS) to retrieve its default management point
and then obtain the management point list from the default management
point. You can use the SMSDIRECTORYLOOKUP client installation property
to specify one of three modes the client uses to retrieve management
point information:
Active Directory Only (NOWINS)—
This mode specifies the client uses only AD to retrieve management
point information. This is the most secure mode; however, management
point communications can fail if the client cannot obtain the
information from the global catalog.
Secure WINS (WINSSECURE)—
Using this mode specifies the client attempts to use AD first and
failover to the WINS method if required. The client communicates only
with the management point after validating its certificate. Secure WINS
is the default mode in Configuration Manager 2007.
Any WINS (WINSPROMISCUOUS)—
Using Any WINS also specifies the client attempts to use AD first and
failover to the WINS method if required; however, in this mode the
client trusts management points without checking their certificate with a
trusted authority. The Any WINS method is the least secure and should
be avoided.
In native mode, the
management point establishes trust with the client by providing a copy
of its certificate signed by a certificate authority (CA) from the PKI
you use to support your native mode deployment. In mixed mode, the
management point presents a copy of its certificate signed with the
trusted root private key. The trusted root key pair is similar to the
public keys used in a PKI infrastructure, but maintained by the central
site server in your ConfigMgr hierarchy for the limited purpose of
supporting ConfigMgr communications. If your site is publishing to AD
clients within the AD forest, it can retrieve the trusted root public
key from AD. You must provision those clients that cannot retrieve the
trusted root key from AD with the trusted root key using the procedure
described at http://technet.microsoft.com/en-us/library/bb680504.aspx.
If you have clients in mixed mode sites not provisioned with the
trusted root key and unable to retrieve the key from AD, they will trust
the first management point they contact.
Securing Site to Site and Server to Server Communications
All communication
between ConfigMgr sites is signed with the sending site server’s
private key. Sites must exchange public keys to verify the signed data
from other sites. To ensure this key exchange is done securely, verify
the Require secure key exchange option is enabled on all sites in your
hierarchy. Require secure key exchange is the default in ConfigMgr.
Sites within the same AD forest can securely exchange keys automatically
if the schema is extended and all sites are publishing to AD. Secure
exchange between sites in
separate forests or without AD publishing enabled requires the
administrator to manually export each site’s keys to a file and import
them at the destination sites.
Communications
between sites are not encrypted. Communications between site systems
within a site use a variety of network protocols.
Most communications between site systems are also not encrypted. You
might want to consider using Internet Protocol security (IPSec) to
encrypt site-to-site and server-to-server communications. IPSec is the
standard encryption protocol for IP networks. For more information on
IPSec, see http://technet.microsoft.com/en-us/network/bb531150.aspx.
IPSec encryption is processor-intensive. For those systems that encrypt
a large amount of network traffic using IPSec, consider installing a
network card that supports IPSec offloading. Microsoft provides specific
guidance for using IPSec to secure ConfigMgr communications at http://technet.microsoft.com/en-us/library/bb632851.aspx.
In addition to
cryptographic controls, ConfigMgr uses Windows access controls to secure
communications between sites and between site systems. Intersite
communications are secured using sender accounts. There are two ways you can configure communications between the site server and other site systems:
If the site system
is in the same AD forest with the site server, you can add the site
system to the Site System to Site Server Connection
(SMS_SiteSystemToSiteServerConnection_sitecode) local group on the site
server. This group has the necessary permissions to connect to the site
server and transfer data. Not all site systems require membership in the
Site System to Site Server Connection group. For more information about
this group, see http://technet.microsoft.com/en-us/library/bb680864.aspx.
If
you enable the Allow only site system initiated data transfers from
this site system option in the properties for the site system, the site
server uses the Site System Installation account to initiate
communications with the site system.
