Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
Distributed Systems Administration Utilities User's Guide > Chapter 2 Configuration Synchronization

Security Notes


Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Index

cfengine has many security features that range from parameters that control denial-of-service attacks to access control lists that prevent managed clients from accessing reference file directories on the server. For details on cfengine security features, refer to the reference manual located in /opt/dsau/doc/cfengine/. The security topics discussed below include:

  • Key exchange

  • Network port usage

  • Encryption

  • Checksum alerts

Key Exchange

All the key exchange examples shown thus far have used scp to securely transfer the master server public key to the managed client and the managed client’s public key to the master server. This scheme provides the highest level of security but can be inconvenient in certain situations. Other key distribution alternatives include the following:

  • When connecting to a new client, cfrun has an interactive mode similar to ssh, where the administrator is prompted to accept the remote system’s key. For example:

    cfrun(0): .......... [ Hailing remote-host.abc.xyz.com ] .......... WARNING - You do not have a public key from host remote-host.abc.xyz.com = Do you want to accept one on trust? (yes/no) -> yes cfrun:master-server-name: Trusting server identity and willing to accept key from remote-host.abc.xyz.com=
  • For large numbers of new clients, interactive mode can be inefficient. cfrun supports a -T option which tells cfengine to trust all new keys from the hosts listed in cfrun.hosts.

  • cfservd.conf supports a TrustKeysFrom control clause. For example:

    control: TrustKeysFrom = ( ) # A trusted host TrustKeysFrom = ( ) # A trusted subnet

    The enumerated host or subnet addresses will be implicitly trusted and their keys automatically accepted.

All of these key exchange alternatives should be used with extreme caution and only in a secure environment where the LAN is trusted and the remote hosts are trusted. Once a public key is accepted it will not be updated unless it is deleted by hand from the master server’s /var/opt/dsau/cfengine/ppkeys directory, manually replaced with a new key, or the csync wizard is run to update it.

csync Network Port Usage

cfservd uses TCP port 5308 by default. You can instruct cfagent to connect to cfservd using a different port by specifying a port in the cfrun.hosts file. For example:

host1.abc.xyz.com # Use standard port host2.abc.xyz.com # Use standard port host3.abc.xyz.com:4444 # Use port 4444

Also, cfengine will honor a cfengine tcp port defined in /etc/services. There are corresponding changes in /etc/services.


In general, file transfer traffic between the master server and a managed client is not encrypted. For many system management related configuration files this is acceptable. For certain files, an encrypted file transfer is desirable. The copy action in cfagent.conf has an "encrypt = true" option to encrypt the specified file. For additional encryption options, refer to the cfengine reference manual located in /opt/dsau/doc/cfengine.

Checksum Alerts

cfengine has a checksum alert feature. To monitor changes to a file’s checksum, do the following:

  • Add the following stanza to /var/opt/dsau/cfengine_master/inputs/cfagent.conf:

    ChecksumUpdates = ( “on” )

  • In cfagent.conf’s "files" actionsequence, add checksum = md5 or checksum = sha options for the files to monitor. For example,

    files: class:: /etc/example mode = 644 checksum = md5

    Note that this checksum option is different from the checksum = true option used in the copy actionsequence. That option tells cfengine to use checksums instead of timestamps when deciding if files need to be copied.

cfagent creates the checksum database on the client if it does not already exist. When ChecksumUpdates is set to "on" or "true", then the current checksum for the monitored files is added to or updated in the checksum database. After this initial run to populate the checksum database, change ChecksumUpdates to "off". At this point, any changes to a checksum of a monitored file causes a security warning. For example:

host1: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! host1: SECURITY ALERT: Checksum for /etc/example changed! host1: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© Hewlett-Packard Development Company, L.P.