Use cfengine to reinforce Solaris servers (below)

 

In the previous article, we introducedCfengineFunctions, components, and Cfengine installation and required processes.Cfengine ConfigurationAnd client system preparation. Use Cfengine to reinforce the Solaris server.

Iv. Cfengine Configuration

　　

Cfengine Configuration

This simple configuration file is divided into four sections, each of which is introduced with a keyword ending with a colon, namely control :( control :), file :( files :), copy :( copy :), and cleanup: (tidy :).

The control section defines a series of directories. We name them tmpdirs, which will be used later (in the tidy :) section ).

The files section specifies that all files in the/usr/local/bin directory should be owned by the root user root and bin groups, the file mode is defined as 0755 (the owner has all permissions and other users have read and execute operations ). When Cfengine is running, it modifies all attributes and permissions that do not match the description of the configuration file. Therefore, this section defines the ownership and license of executable files in the Local Binary directory.

The copy section describes different configuration methods for Linux and Solaris systems. In the Solaris system, when files in the/config/pam/solaris directory on the master server are updated, files in the/etc/pam. d directory are also updated. In Linux, only the file/etc/pam. d/common-auth is updated with the update of the PAM master configuration file. Note that these two specifications execute the same underlying system configuration and maintenance policy: When necessary, the relevant PAM Configuration files will be updated from the master server.

The Section tidy illustrates the use of implicit loops. The single indication in the example is applied to each directory file in the tmpdirs list. For each directory, Cfengine deletes all the items in the directory, or any item in the subdirectory that has not been used for any seven days (including the names of files starting with the DOT ). Like other guidelines in this example configuration file, this section executes the policy of deleting projects in temporary directories that are not used within a week. All Cfengine configuration files have different descriptions in the aspects described above and other similar elements. The descriptions of some elements are more detailed and specific.

　　1. Create a basic configuration file

These configuration files must be placed in the master configuration directory on the configuration server. These files are all public files that are initially used on each server on the network.

(1) cfservd. conf example

The following is the configuration file of the cfservd daemon. It allows the client to transmit the master configuration file set and remote cfagent execution through cfrun. Obviously, only one system allows access to the central configuration file (server), but allowing cfservd to access these files does not harm any files on other systems (because they do not copy these files ). However, all systems can benefit from remote cfagent execution because it allows cfagent execution on demand from remote systems. Therefore, the following cfservd. conf can be used in all systems, which is exactly what we need:

 

Control: Domain = (mydomain.com) AllowUsers = (root) CfrunCommand = ("/var/cfagent/bin/cfagent ") Admit: /Usr/local/var/cfengine/inputs * .mydomain.com /Var/cfagent/bin/cfagent * .mydomain.com

 

Cfrun Command specifies the location of the cfagent binary file to be executed when a connection from cfrun is received. The admit segment is very important because it specifies the host to access which file. You must grant access to the central configuration directory and the cfagent binary file. You also need to grant access to any other files that the client needs to transfer from this server.

　　2. Create a configuration server

The configuration server contains the master copy of The cfengine configuration file. It also periodically processes the configuration file like all client systems. The server must run the correctly configured cfservd so that the client system can retrieve the master configuration file from the system. The configuration server needs a special location to save the cfengine master configuration file. In this example, the location is/usr/local/var/cfengine/inputs /. This location can be any directory except/var/cfengine/inputs/, because important hosts copy files to this directory like other hosts during execution.

Like all systems, this server should also run cfexmcm as a daemon or from cron (preferably both.

Run the cfkey on the server system to create the public key and private key file. These files are located in the/var/cfengine/ppkeys/directory and named localhost. priv and localhost. pub. Then copy localhost. pub to a new file in the same directory. This file should be called a root-10.1.1.1.pub, assuming that your IP address is 10.1.1.1. You only need to connect the cfrun command to itself, but it is useful to execute this operation anyway. Based on the IP address of the client described in the following section, the server also needs to save the public key of each client in the appropriate file.

 

3. Prepare the Client System

The configuration of the client system is relatively simple. Once the actual cfengine binary file is installed, an appropriate public key (as described in this section) needs to be generated and copied ). You also need to manually copy the update. conf file from the master server and put it in/var/cfengine/inputs. After saving the file in the correct location, manually run the cfagent to download the remaining configuration files and complete the system configuration. Each client should run cfexmcm in the form of a daemon or from cron. Cfservd may be run on each client and cfrun can be used to remotely execute cfagent. Assuming that the configuration has been completed in the cfagent. conf file on the server, these daemon will be started when the cfagent is manually executed for the first time.

The following code generates a client key and runs the cfkey on each client system. This operation creates localhost. priv and localhost. pub in/var/cfengine/ppkeys. Then, copy the public key of the central server to the client. If the server IP address is 10.1.1.1, copy its public key to the root-10.1.1.1.pub in the/var/cfengine/ppkeys/directory on the client. Finally, copy the Public Key (localhost. pub) of the client to the/var/cfengine/ppkeys/directory of the server. In addition, this file should be named according to the client's IP address (if its IP address is 10.2.2.2, this file should be named root-10.2.2.2.pub on the server ). This can be done manually or automatically in the initial system configuration script.

　　4. Use cfrun

The cfrun command allows cfagent to be executed on any number of systems on the network. It must include the configuration file cfrun. hosts in the current directory (or the file specified by the-f option ). The file content should be as follows:

 

Domain = mydomain.com Server.mydomain.com Client1.mydomain.com Client2.mydomain.com

 

In addition to domain settings, this file only contains a list of each host (including servers. By adding the following options to the top of the file, you can also record the output to a series of files (not displayed on the screen ):

 

Outputdir =/tmp/cfrun_output Maxchild = 10106

 

The code above tells cfrun to generate 10 processes and save the output of each host to different files in the specified directory. You can run cfrun without parameters. If you want to specify a parameter, the format is as follows:

CfrunCFRUN_OPTIONSHOSTS -- The CFAGENT_OPTIONS-CLASSESCFRUN_OPTIONS is optional. You can include any number of options for the cfrun command. You can specify an optional list of host names. If you have specified some hosts, contact them only. If no host is specified, contact each host in the cfrun. hosts file. The first one is followed by any option that is run on each remote system and is sent to the actual cfagent command. The second -- is followed by an optional list of classes. If some classes are specified, only the host that matches one of the classes will actually execute the cfagent (although each host has been contacted, because each host must decide whether it matches one of the classes ).

 

5. application instance: security reinforcement for Solaris servers

If you have read most of the content before this article, you will know that cfengine is great. Once cfengine is installed and running, it can do anything for you, including Security Hardening of Solaris servers.

Cfengine can improve system security in many aspects. First, it allows you to automatically configure the system in a unified way. Cfengine configurations can be used to quickly apply changes to other hosts in the same class or other classes, or even to systems that are not yet installed. This means that if the security problem on the unix system is corrected through the cfengine, and a new unix system is installed later, the same security issues on the new system will be solved (if necessary ).

1. Use cfengine to perform basic file checks

Cfengine automatically performs security checks on all files and directories mentioned in the files section. First, it reports and records the files that are setuid or setgidroot (one file can only be reported once at most ). The executable setuid and setgid Files enable the program to run as a specific user (such as root), regardless of who actually executes the command. Obviously, this is a powerful but dangerous feature.

In addition, when processing files, tidy, and copy segments, cfengine identifies suspicious files. You can use the following settings to control this behavior:

 

Control: NonAlphaNumFiles = (on) FileExtensions = (oacgifjpghtml) # etc SuspiciousNames = (. molrk3lkr3)

 

The first setting causes the cfengine to report and disable non-letter and number files it discovers. The second setting (FileExtensions) contains a column of standard file extensions. Since users may try to create them using standard file extensions, cfengine reports them if it finds directories with these extensions. SuspiciousNames identifies the files that will generate a warning if discovered.

2. Use cfengine to disable various files and programs on the System

You can use cfengine to disable various files and programs on the system. When executable files and other files are disabled, rename them with the. cf-disabled extension and set their permissions to 0400. Example:

 

Disable: Any :: /Root/. rhosts /Etc/hosts. equiv Solaris :: # Someversionsprovidealocalrootexploit /Usr/bin/eject278

 

In the first section, files/root/. rhosts and/etc/hosts. equiv on all systems are disabled because these files are often considered dangerous.

3. Use cfengine to ensure file security

Cfengine can be used to ensure proper access to important system files. The following example shows how to set permissions on the system account file:

 

Files: /Etc/passwdmode = 644 owner = rootgroup = rootaction = fixall /Etc/shadowmode = 600 owner = rootgroup = rootaction = fixall /Etc/groupmode = 644 owner = rootgroup = rootaction = fixall

 

You can also use cfengine to monitor binary files on the system. Like other files, the permissions of binary files can be checked and any problems can be fixed. This is a very useful feature for binary files, especially those setuidroot files. You can also use cfengine to provide some Tripwire functions-you can use it to monitor the md5 checksum of a file. Example:

 

Files: /Bin/mountmode = 4555 owner = rootgroup = rootaction = fixallchecksum = md5

 

In many systems, the/bin/mount program is setuidroot. This allows users to mount a specific drive without the need for superuser permissions. The parameters in this example allow cfengine to check the permissions of the binary file (and all other files belonging to setuidroot) and check its checksum in the database. If the checksum is changed, you will be notified every time the cfagent runs. This continues until the cfagent is executed using the following settings in the control Section.

 

Control: ChecksumUpdates = (on)

 

This setting updates the checksum of all stored files to the current value. You can also ask cfengine to find and remove any setuidroot files that you have not specifically listed:

 

Filters: {Root_owned_files Owner: "root" Result: "Owner" } Files: / Filter = root_owned_files Mode = u-s # noSUIDbitmaybeset Recurse = inf Action = fixall Inform = true # Andthefullpathsoffilesthat * shoshould * beSUID Ignore =/proc Ignore =/bin/ping Ignore =/usr/bin/su Ignore =/usr/bin/passwd Ignore =/usr/bin/ Ignore =/usr/bin/crontab Ignore =/usr/bin/rsh Ignore =/usr/sbin/traceroute

 

The above code recursion the entire file system, and disable the setuid bits of all files owned by the root. I use the ignore option to exclude files that I want to set as root. You can also ignore directories with this command (in this case/proc /). Make sure that the complete path name is used. Although you can use ignore = ping to replace ignore =/bin/ping, the file/home/hackeduser/. hidden/my_fake_ping may be ignored inadvertently. Note that this example is not widely used. If you want to put it in a valid cfagent. conf, it may mess up the system. The reason is that each operating system has a different root program, so that it can run normally.

 

 

4. Use cfengine to Control Network Services

First, you should disable all unnecessary processes on each system, especially those that accept network connections. You may need to run at least a certain number of services. You can use the TCP package to restrict access to these services.

1. Disable the inetd service

You can use cfengine to quickly disable services started from inetd. For example, you want to disable the "r" Service (rsh, rlogin, etc ):

 

Editfiles: {/Etc/inetd. conf HashCommentLinesContaining "rshd" HashCommentLinesContaining "rlogind" HashCommentLinesContaining "rwall" DefineClasses "modified_inetd" }

 

Because the "r" service actually uses the system's inetd to listen to sockets, I just comment out some entries in the inetd configuration file (in some systems, it is/etc/inetd. conf, while/etc/inet/inetd in other systems. conf ). The request defines the modified_inetd class -- but only when changes are made. When this class is defined, you can use it to send an HUP signal to inetd so that it can re-read its Configuration:

 

Processes: Modified_inetd :: "Inetd" signal = hup

 

2. Disable the daemon

By default, many processes may run on the system. You may find that many of these processes do not need to listen for remote connections on the port. To disable these processes, you must first make sure that the problematic process is not running. Cfengine is easy to implement. For example, assume that the system does not use the NFS--NFS to use several processes to terminate:

 

Processes: "Nfsd" signal = kill "Rpc. statd" signal = kill "Rpc. rquotad" signal = kill "Rpc. mountd" signal = kill

 

If these processes are running, they will be terminated every time the cfagent runs.

　　Summary:This article describes how to use cfengine to reinforce Solaris servers. It can also be used in Linux, BSD, HPUX, and other Unix-like systems.