Architecture

Principles

• minimal footprint on the systems
  Only basic posix shell and standard awk functionality is used. The webinterface is CGI based and displays generated HTML.
• single code base
  All systems run the same code to minimize maintenance. Used programs and files are checked before access.
• sane defaults
  SCC uses sane defaults to minimize configuration effort. On the vast majority of systems, SCC will run correct out of the box.
• minimal interpretation of collected data
  Besides the classification of the kind of data and the fixed and variable nature of it, the collected data is hardly interpreted. SCC is not a security or monitoring application, however it can provide data for such applications.
• minimize changes in the logbook
  The goal is to limit detected changes to actions by administrators.
• ease of installation
  The software is available in many, native install formats.

Deployment

The deployment and transfer of data from client to server of SCC are shown here:

Client

The technology used by the clients to collect configuration data, differs between Unix/Linux/*BSD and Windows. On Unix/Linux/*BSD-systems configuration-files and the output of system-commands are incorporated in the snapshots. On Windows systems data is retrieved through the Windows Management Interface. The scriptomatic tool from Microsoft is used to generate perl code that is used to collect data. Several GNU tools and ActivePerl are used to process the collected data. Running it as domain administrator makes it possible to collect data from other systems in your domain. The client for Unix/Linux/*BSD system is quite mature. The Windows client does not yet collect as much data. Therefore it is likely that certain changes on your Windows-systems are missing in the logbook. The remainder of the functionality of the SCC client on Windows and Unix/Linux/*BSD is similar.

The Unix/Linux/*BSD client and server software are available in many native install formats. The Windows client consists of perl scripts to collect and manipulate the data. The WIX toolset is used to pack these scripts and some GNU .dll and .exe files in a 32-bit MSI.

Basically, the SCC client extends each line of collected data with a hierarchical classification based on the nature of the data and with an indicator that states whether that data is supposed to be static or dynamic. Consecutive collections of configuration data (snapshots) are compared and the resulting differences in static data are added to the logbook. For example: the size of a file system is static data and the current usage is dynamic data. The usage a file system will not be reported in the logbook, but the extension of the file system will.

The reach of the clients can be extended by adding user-modules. The client software contains a prototype program (scc-plugin) that can be altered to capture any configuration data. Rename this program and activate it on a regular basis through the -e option of scc. The configuration data captured by this module becomes part of the regular snapshot. Changes in this configuration data are recorded in the logbook of the system. Refer to scc-plugin, scc-plugin (Windows), and scc-collect for more details.

On several occasions the system programs called by the collection program scc-collect produce unexpected output. This output is captured under the classification "fix:messages::". After installing the SCC client, check your snapshot and search for messages. Up to now, most of these messages indicate either a hard- or configuration error on the system. During the collection process, many programs are called. The absence of messages can be interpreted as an indication of the health of the system.

Program scc-collect and its modules use sensible defaults to avoid that many systems require a configuration file. When the defaults are insufficient, copy /etc/opt/scc/newconfig/scc-localize to /etc/opt/scc/conf/scc-localize and uncomment the required variables. Be sure to preserve the execution permission of the file.

Feel free to contact us when you want to contribute your extensions. We will distribute them on this website.

For more information, refer to the manual pages of the Unix/Linux/*BSD client and Windows client.

Server

On the server, summaries of the SCC-data are generated and search/compare operations are available via a web-interface. The complete functionality of the server part of SCC consists of:

• receive files sent by scc from client systems
• transfer of these files to the directory used by the web server
• summarize data in the received files
• allow search and compare functionality through a web server

The SCC data can be sent from clients to the server by email, scp, rcp or cp (local/NFS). The manual page of scc-srv describes the setup of the server to enable this functionality.

The snapshots contain much sensitive data. Use .htaccess files to restrict access to the snapshots. Refer to scc-realm for a description of the proper setup of permissions.

For more information, refer to the manual pages of the Unix/Linux/*BSD server.

Security

Several of the configuration files and programs that are used to collect a snapshot by the SCC client, can only be accessed by root. Therefore the SCC client has to run as root. To be safe, the software uses separate directory trees that are created with specific permissions and ownership to avoid tampering. Programs, manuals and documentation reside under /opt/scc and datafiles under /var/opt/scc. Both directory trees are owned by root:sys and have no permissions for group and other. Refer to the instructions in the relocate script in the source tarball to install the software in other directories.

Each program of SCC starts with the following code:

• set the PATH variable to a specific list of directories
• umask 077 avoid group and other permissions for new and temporary files
• cd /var/opt/scc/tmp a safe place for temporary files that might be created when the software runs
• set TEMPDIR and TMP to /var/opt/scc/tmp a safe place for temporary files
• set SHELL to the shell to be used (either ksh or POSIX-shell)

The resulting snapshots and log files should be transferred to another system to be available after a fatal crash of the system on which the software runs. The software does not provide any mechanism to achieve this. Use whatever software you are already using: scp, gpg, ftp, encrypted email or rcp.

SCC server consists of three different parts. The first is (optionally) used to receive SCC data through email. It is a minimal program run through an alias and by the user running the mail-server. The second part is used to transfer SCC data from the transfer-area to the web server and generate summaries. This part has to set the ownerships of files to the user running the web server and the groups owning the realms. Therefore this part of the software is run by root. It should be activated on a regular basis by cron. The last part of the software is the CGI-script running under the user of the web server.

Refer to scc-srv(5) and scc-realm(1) for detailed descriptions of restricting access to SCC data.

The server receives SCC-data from clients by email, scp, ftp or rcp. A Denial Of Service is possible by frequently sending large snapshots of fake hosts to the SCC server. Furthermore, anyone can (re)send SCC-data from any system to the SCC server. Therefore, the SCC server should only be deployed in a trusted network.