2. Installing Beltane

2.1. System Requirements

Beltane requires

2.2. Usage Requirements

In order to make use of Beltane, you need a working installation of the samhain version 1.6.1 or higher file integrity / intrusion detection system.

Your installation of samhain must be configured as client/server system, with file signature databases and client configuration files stored on the central server, and with logging to a MySQL, PostgreSQL, or Oracle database enabled. (For step-by-step instructions to setup samhain, see Section 2.10).

Beltane must be installed on the central log server. This is required for filesystem access to the baseline databases stored on the log server.

If you are using the stealth (or micro-stealth) option for your samhain installation, the value of XOR_VAL must be the same for all clients.

2.3. Configure


Obviously, Beltanes functionality requires read/write access to the log servers data directory and the files therein. There are some different ways to accomplish this, with respective security implications. Please read Section 2.8.4 carefully, and make your own decision.

To configure Beltane for installation, run the ./configure shell script in the source directory. ./configure takes the following arguments:

2.4. Installation

To install, use make && make install.

2.5. Fixing filesystem access permissions


There are plenty of ways to install yule (the samhain server) and beltane, so here we just discuss an example. However, this should give you an idea what to fix if things do not work. DO NOT blindly follow this example without thinking first.

In particular, we assume: PHP is php_mod (not cgi), users 'www' (webserver), 'beltane', and 'yule' (samhain server) exist, and beltane and yule are in group 'samhain'. Beltane helper applications will be set SUID/SGID beltane/samhain, and the Yule directory layout is LSB (Linux standard base), which is the default.

See also Section 2.8.4 for some more information.

Webserver access to beltane

As you have installed the beltane PHP scripts into some directory DIR (configure option --with-php-dir=DIR), you should make sure that the webserver has read access to this directory and everything below it

bash$ chown -R root   DIR 
bash$ chmod -R 555    DIR 

Access to the yule data directory for user beltane

For security, we do not give the webserver access to the data directory, but transfer privileges by making the beltane helper applications SUID/SGID beltane/samhain. Accordingly, user 'beltane' needs read/write access, and group 'samhain' (yule) needs read access.

bash$ chown beltane:samhain   /var/lib/yule 
bash$ chown beltane:samhain   /var/lib/yule/rc.* 
bash$ chown beltane:samhain   /var/lib/yule/file.* 

Access to the yule HTML status file

This file is only re-written by yule, so yule will not change the permissions. It needs to be readable from PHP (i.e. for user 'www' in our example).

bash$ chmod 644 /var/log/yule/yule.html 

Public and secret PGP keys for signing

If you are using signed configuration and database files, the user 'beltane' needs access to the keys. Signing is done using the helper application beltane_sign, which is SUID/SGID beltane/samhain in our example. With this example, you would then configure 'GPG Homedir' to DIR/.gnupg in the Beltane configuration screen.

bash$ cp -r ~/.gnupg DIR/ 
bash$ chown -R beltane:samhain DIR/.gnupg 

Access to the database of installed clients

This is the XML format database of installed clients. It can be created through the beltane interface, but if you are using the samhain deployment system, it is created and maintained automatically by that system.

bash$ chown beltane /var/lib/yule/profiles 
bash$ chmod 755     /var/lib/yule/profiles 
bash$ chown www:samhain /var/lib/yule/profiles/yulerc.install.db
bash$ chmod 660         /var/lib/yule/profiles/yulerc.install.db

Set helper applications SUID/SGID beltane/samhain

bash$ chown beltane:samhain /usr/local/bin/beltane_* 
bash$ chmod 6755            /usr/local/bin/beltane_* 

Ownership of log directory

With --with-logfile=LOGDIR/FILE you can set an appropriate path at compile time.

bash$ chown beltane:samhain LOGDIR

Access to the yulectl utility

This utility is installed with mode 700 by default, but can be set 755 without security implications. You need it if you want to ask clients to reload their configurations via the web interface, or if you want to perform on-demand file integrity checks.

bash$ chmod 755 /usr/local/sbin/yulectl 

The 'yulectl' utility is just an interface to a UNIX domain socket opened by the yule server. It will not work if (1) the server does not open the socket, or (2) authenticating to the server does not succeed. In turn:

(1) in the [Misc] section of the yule configuration, set 'SetUseSocket = True'

(2a) if your operating system supports passing credentials over a socket (Linux and *BSD do), set 'SetSocketAllowUid=UID', where UID is the one of user 'www'.

(2b) if your operating system does NOT support passing credentials over a socket, set 'SetSocketPassword = PASSWORD' (choose any password you like), and create a file .yulectl_cred in the HOME directory of the user 'www'. This file must contain a single line with only the PASSWORD. It must be readable for user 'www'.

TipWhich authentication method is supported on your OS?

If you run yule -v, yule will tell you whether authentication by UID or by password is required.

2.6. Postinstallation configuration

Point your browser to the index.html file in the php-dir where you have installed Beltane, login with the default user/password:


It is perfectly normal if you see a bunch of error messages about access to the database — beltane does not know yet how to access the database, you have to configure that first.

Click on Configure in the main menu (upper panel), and change user and password.

You may also need to change the defaults for access to the SQL database (like username, password, database name, table name).


Beltane will require both SELECT and UPDATE privileges to the SQL database. The default SQL database init script for yule (from the samhain tarball) may not set UPDATE privileges for anyone. You are advised to review the SQL permissions, otherwise Beltane will not work properly.

You may or may not want to create a separate SQL database user for Beltane (the yule log server does not require UPDATE privileges, thus can access the SQL database as a less privileged user).

2.7. Upgrading

WarningUpgrade to version 2.4.0 of Beltane II

As of version 2.4.0, regular expressions for message filters are Perl Compatible Regular Expressions (PCRE) instead of POSIX regular expressions (rationale: POSIX regex functions are deprecated as of PHP 5.3) Please note that PCRE regular expressions must be enclosed by matching delimiters. Since the closing delimiter can be followed by qualifiers (e.g. /pattern/i for case-insensitive evaluation of 'pattern'), this cannot be upgraded automatically.

WarningDatabase scheme change for samhain 2.8.0+

As of version 2.8.0, Samhain supports IPv6 now, which means that the size of the 'ip' column in the database must be increased from VARCHAR(16) to VARCHAR(46).


        ALTER TABLE samhain.log MODIFY ip VARCHAR(46);


        ALTER TABLE samhain.log ALTER COLUMN ip TYPE VARCHAR(46);


        ALTER TABLE samhain.log MODIFY ip VARCHAR(46);

WarningDatabase scheme change for samhain 2.4.4+

As of version 2.4.4 of Samhain, it is possible now to store the full content of small files in the baseline database. To support this feature with logging to an RDBMS, the DB schema for Oracle needs to be adjusted by converting the link_old, link_new columns from VARCHAR2 to CLOB:

Oracle (MySql, PostgreSQL not affected):

      ALTER TABLE samhain.log ADD tmp_name CLOB;
      UPDATE samhain.log SET tmp_name=link_old;
      ALTER TABLE samhain.log DROP COLUMN link_old;
      ALTER TABLE samhain.log RENAME COLUMN tmp_name to link_old;

      ALTER TABLE samhain.log ADD tmp_name CLOB;
      UPDATE samhain.log SET tmp_name=link_new;
      ALTER TABLE samhain.log DROP COLUMN link_new;
      ALTER TABLE samhain.log RENAME COLUMN tmp_name to link_new;

WarningDatabase scheme change for samhain 2.3.0+

Version 2.3 of Samhain supports checking of SELinux attributes and/or Posix ACLs. For backward compatibility, this is off by default. If you upgrade Samhain and enable this option, you need to update the database scheme as follows:


        ALTER TABLE samhain.log ADD COLUMN acl_old BLOB;
        ALTER TABLE samhain.log ADD COLUMN acl_new BLOB;


        ALTER TABLE samhain.log ADD COLUMN acl_old TEXT;
        ALTER TABLE samhain.log ADD COLUMN acl_new TEXT;


        ALTER TABLE samhain.log ADD acl_old VARCHAR2(4000);
        ALTER TABLE samhain.log ADD acl_new VARCHAR2(4000);
        DROP TRIGGER trigger_on_log;

If you are upgrading from a previous version of Beltane, after login you should first click on Configure in the main menu (upper panel), and check for new configuration options that may need to be configured correctly.

New in version 0.3: pid_file (the path to the pid file of yule,the log server, and html_file (the path to the HTML status file of yule).

New in version 0.4: n_messages (the maximum number of messages to display, use 0 to display all).

New in version 2.0: Filter messages (POSIX regular expression; matching messages will not be displayed, and optionally their status will be set to 'acknowledged').

View server messages (boolean option; if TRUE, messages from yule, the log server, will also be displayed).

Sort clients by name (boolean option; if TRUE, clients will be sorted alphabetically rather than by highest severity of new messages).

Additional users can be defined

GPG signing of file signature databases

New in version 2.0.2: Multiple filters can be defined.

New in version 2.0.4: Reload commands for clients can be submitted to the yule server.

Editing of client configuration files is possible

Bulk Update has been modified for improved speed

New in version 2.0.13: The file list for bulk updates may include checksums.

New in version 2.1.0: New user interface. Manually selecting for update will automatically create a corresponding file list.

New in version 2.1.1: Works with Oracle now. Client editing adapted to deploy.sh version 2.

New in version 2.1.2: Search function for database. New configuration item 'Comment updates' (boolean) to select whether to store update info in the database. User is logged for updates.

New in version 2.2.0: Revised filter options, and more configurable interface.

New in version 2.3.0: Hosts and users can be divided into groups. LDAP authentication or browser-based login is possible if HTTPS is used for the connection to beltane. Comments for updates are enforced if comments are enabled.

New in version 2.3.4: User can set their own preferences, filters, GPG key, and password. Multiple admins are possible.

New in version 2.3.7: If file contents are stored, it's possible to view a diff for reported modifications.

New in version 2.3.9: It's possible to request an on-demand file system check for clients.

New in version 2.3.20: Enhance search function to diff filesystem changes for clients.

New in version 2.4.0: Replaced POSIX regular expressions (filters, host and path in bulk update) with Perl Compatible Regular Expressions (PCRE) since the PHP POSIX regex functions are deprecated as of PHP 5.3. Enhance search function to search for file renames.

2.8. Security

2.8.1. mod_php vs. CGI PHP

If you have untrusted users which can create their own php scripts, mod_php is not secure, since every php script runs under the same UID (the one of the webserver). Either install CGI PHP and use the Apache suexec wrapper to execute each users' scripts under the user UID, or use a dedicated server for Beltane with no untrusted users.

2.8.2. Login

Beltane uses a challenge-response protocol for authentication. To login, the client browser receives a nonce, and sends back the MD5 hash MD5(username MD5(password) nonce). If there is no user action within some timeout interval (by default 600 sec), the user is logged out automatically.

The default login is user/pass = rainer/wichmann. You may want to change this as soon as possible, using the configure option in the menu panel (the upper panel).

You can also use the makepasswd.pl Perl script (which is included in the Beltane source tarfile) to compute an MD5 password hash and insert it manually in the beltanerc file: makepasswd.pl password

2.8.3. SQL Access

Beltane can be used to acknowledge messages in the database, i.e. note that you have checked the message. This requires update privileges for the database.

You can set the SQL database user and password in the configuration file of Beltane. It is recommended to have one user with select and insert privileges for yule (the samhain log server), and another user with select and update privileges for Beltane.

2.8.4. Data access

To update the file signature databases of clients stored on the server, Beltane requires read and write permission for these files, and for the directory within that they reside.


The server (i.e. Yule) only needs read access to this directory and the files therein. This allows to chown the data directory to another user, as long as Yule has read access (note that due to a bug, as of yule 1.7.7 only the primary group will be considered for read access).


Writing to the data directory is not performed by the beltane PHP process, but by helper programs (beltane_cp, beltane_log, beltane_sign and beltane_update). This allows to perform write access not with the privileges of the webserver / PHP process, but with the privileges of some other user (by making these helper programs SUID 'user', where 'user' should not be 'root').

The PHP process still needs read access for the 'undo' function.

The recommended setup would be as follows:


Create a group (say, samhain) and two users (say, yule, and beltane) with that group.

Data directory

Now make beltane the owner of the yule data directory (usually /var/lib/yule), as well as of all the client configuration and database files therein. Make the directory, and the aforementioned files, group readable for the group samhain.

If you use mod_php

The beltane PHP scripts will be executed with the UID/GID of the web server. To get write access to the yule data directory, you should make the helper executables (beltane_update et al.) suid beltane. To do so, you need to chown beltane:samhain beltane_update, and set the suid and sgid bits with chmod 6755 beltane_update (and likewise for the other helper executables):

bash$ chown beltane:samhain beltane_update 
bash$ chmod 6755      beltane_update 

Using the configure option --enable-postinstall=suid will set the helper programs suid/sgid to the current owner and group of the yule data directory upon installation.

If you use CGI php

There are two possibilities:

a) If you use the Apache suexec wrapper to execute Beltanes PHP scripts, you can have them executed as user beltane.

b) If you don't want to use suexec, the PHP scripts are executed with the UID of the webserver. This is the same case as with mod_php (see above).

Note that the data directory must be readable for the PHP process. You may want to include Apache in the samhain group, if you don't use suexec.

2.8.5. Using an SSH Tunnel

For improved security, you may want to access the webserver on the machine running yule via a secure SSH tunnel only. This can be done in the following way:

On the machine where yule is running, change the apache config file (httpd.conf) as follows: change BindAddress * to BindAddress, and Listen to Listen Afterwards, restart apache — it will now honour only requests from localhost.

Create an SSH tunnel from your machine to the server with:

bash$ ssh -C -L 2080: Server_Address 

In your browser, type the address http://localhost:2080

2.9. Backups

Beltane uses four C programs: beltane_cp, beltane_update, beltane_sign, and beltane_log to perform actions that require write permission to data in the yule data directory or to Beltanes global log file. These programs can only be used by root and optionally by a single other user (see Section 2.3.

beltane_cp will copy a temporary file to the location of the database of installed clients. This database is a flat file in XML format, named yulerc.install.db, and located in the profiles/ subdirectory of the yule data directory. All calls to beltane_cp are logged in the Beltane log file. Upon first access, a backup is created with the extension .old. On further accesses, another backup is created with the extension .bak, that is overwritten if it is older than one day.

beltane_update will update client file signature databases according to its command line arguments. All calls to beltane_update are logged in the Beltane log file. Upon first access, a backup is created with the extension .old. On further accesses, another backup is created with the extension .bak, that is overwritten if it is older than one day. In addition, for each file signature database an inverse log with the extension .log will be written. This inverse log contains for each action the required command to undo that action (plus a comment with the original command). Thus, to undo the last 5 changes on (e.g.) file.client.mydomain.com, you could do:

bash$ tail -10 file.client.mydomain.com.log | tac | /bin/sh 

For the last action, an inverse log with the extension .log.last is written, which is used in the undo option that is displayed after performing an update.

beltane_sign will clearsign a file. It is used with Beltanes signing function to re-sign updated files.

beltane_log will write an entry to the global log file. It is mainly used to track user login/logouts.

2.10. Samhain configuration

To install a samhain/yule client/server system, you may proceed as follows (this looks a bit involved, but much of it, e.g. server installation and SQL database preparation, is only required the first time):

      # build the server (with PostgreSQL support)
      $ ./configure --enable-xml-log --with-database=postgresql \
      $ make
      $ make install && make install-boot
      # build the client (support fetching database/config from server)
      $ ./configure --enable-xml-log --enable-network=client \
       --with-data-file=REQ_FROM_SERVER/var/lib/samhain/samhain_file \
       --with-config-file=REQ_FROM_SERVER/etc/samhainrc \
      $ make
      # - Create a password (16 digits hexadecimal, i.e. 0…F),
      # - Register the client with the server
      # - Set password in client, install the client, init database
      $ SHPW=`yule -G`
      $ yule -P $SHPW | \
       sed s%HOSTNAME%client.yourdomain.com% \
       >> /etc/yulerc
      $ ./samhain_setpwd samhain new $SHPW
      $ mv samhain.new samhain
      $ make install && make install-boot
      $ samhain -t init

Now, edit /etc/samhainrc and enable logging to the server by setting an appropriate logging threshold:


Next, copy the client configuration file and the database of file signatures to the server:

      $ scp /etc/samhainrc root@server.yourdomain.com:/var/lib/yule/rc.client.yourdomain.com
      $ scp /var/lib/samhain/samhain_file root@server.yourdomain.com:/var/lib/yule/file.client.yourdomain.com

On the log server, create the database and use the init script provided in the source directory to create the table:


The PostgreSQL init script will grant insert permission without password to a user 'samhain'. The MySQL init script will not set any permissions. You may want to read the MySQL/PostgreSQL docs and review the permission setup. It is recommended to set a password, and allow connections only from localhost.

      $ su postgres
      $ createdb samhain
      $ createuser samhain
      $ psql -d samhain < samhain.postgres.init
      $ exit

… and edit the server configuration file /etc/yulerc to enable SQL logging:



Now you can start yule, the server, and thereafter on the client machine samhain, the client:

      $ /etc/init.d/yule start
      $ /etc/init.d/samhain start