Samhain | ||
---|---|---|
<<< Previous | Next >>> |
samhain includes a system to facilitate deployment of the client to remote hosts. To use this system, the following requirements must be met:
You must have compiled the server (yule) on the local host from which you distribute, and it must be in your PATH
For each operating system type, there must be (at least) one host where development tools (C compiler, make, strip) are available to build the client.
On each remote host, you must be able to login as root with ssh.
There are two major parts of this system:
A directory profiles that for each system type (OS & machine) of remote systems holds a subdirectory (the subdirectories profiles/os-machine/ in the source tree) that includes the following files:
configopts — holds the build configure options, i.e. the options given to configure when building the samhain executable on the remote host,
samhainrc — holds the configuration file for the samhain executable, and
bootscript — is a script that modifies the remote host system configuration to make samhain start upon booting.
A script deploy.sh (created by configure from deploy.sh.in) that, on execution, will:
create a mini-distribution samhain-deploy.tar.gz,
copy it to the remote host,
compile (if needed) or install the samhain client,
initialize and retrieve the database (and the compiled binary), delete the database on the remote host, and
store the client's credentials (by default) in a file profiles/yulerc.clients. (This is what goes into the Clients section of the server config file).
store the client's file signature database by default in profiles/file.hostname, and
store the client's config file by default in profiles/rc.hostname.
After building the client on one host of some system type, the executable will automatically be retrieved and stored in profiles/os-machine/ for further distribution. No development tools (compiler, make, strip, install) are required then on other hosts of the same type for deployment of the compiled executable to them.
deploy.sh takes the following arguments:
-v$|$--verbose Verbose output
-f$|$--force Force recompilation, even if compiled binary available
-p$|$--pack Pack the executable
-o$|$--overwrite When installing, overwrite an existing rc file for the client.
--remote-host=HOST Deploy to this host (if not building). Not required if you want to compile.
--build-host=HOST Build on this host. Not required if you already have compiled for this architecture. Note that you can either build or deploy, but not both with a single run of the script.
--build-OS=OS The architecture of the build/deploy host. Used to select the proper profiles/os-machine subdirectory.
--build-dir=DIR Directory on the remote (build/deploy) host where the files will be unpacked, and eventually compiled. If this directory or one of its parents is writeable by others than root, you should have given a list corresponding list of trusted UIDs (see next) when building.
--trusted-uids=UIDS List of trusted uids on the build/deploy host (required if the --build-dir or one of its parents is writeable by others than root). Must be given at compile time.
--add-path=ADDPATH Directories (in the format path1:path2:...) that should be appended to the PATH variable on the remote host.
--build-user=USER Perform a su to this user when compiling on the build host.
--prefix=PREFIX The PREFIX given to ./configure when compiling on the build host.
--xor-code=XOR The XOR code for (micro-)stealth (if you use --enable-[micro-]stealth in profiles/architecture/configopts
--nocl-code=NOCL The NOCL magic string for the --with-nocl option.
--base1=BASE1,--base2=BASE2 The base keys for verifying e-mail/log entries. This should be the same for all binaries on your network.
--loghost=HOST The host on which the server will run.
--install-name=NAME The name under which the client will be installed.
--clients=FILE Add client's credential to this file. If FILE is the server's config file, and has a Clients section, add to this section. If there is already an entry for the remote host to which you just have deployed, replace this entry. Note that a temporary file might be created, thus FILE should be in a secure (not world-writeable) directory.
--client-files=DIR Copy the remote host's database and the config file to this directory. Ideally this would be the server's data directory (see the Section called Paths in the appendix called List of compilation options>), from where the server will fetch the files when the client requests them for download.
Deployment occurs in two separate stages: First, you need to build the executable on some host, using the --build-host option of deploy.sh. Second, you can then distribute to other hosts using the --remote-host option of deploy.sh.
You must run configure first, and compile and install the server (yule), before using deploy.sh.
yule must be in your PATH, if deploy.sh is not used from the top source directory. It is not necessary to have the server running, though.
It is recommended that you use make install-deploy to install the required files of the deploy system to to the samhain data directory (see the Section called Paths in the appendix called List of compilation options>), and deploy.sh to sbindir, i.e. the same directory where yule gets installed.
deploy.sh uses ssh/scp. You need to have the sshd daemon running on the remote host. It is helpful if RSA-based authentication is possible for root, otherwise you have to type in your password quite a few times.
![]() | TIP | |
---|---|---|
To use RSA-based authentication in a secure way, it is recommended to proceed as follows: Use ssh-keygen to create a public/private key pair. Don't forget to set a passphrase for the private key (ssh-keygen will ask for it). Copy the public key (HOME/.ssh/identity.pub to HOME/.ssh/authorized_keys on any remote host where you want to log in. Do not copy the private key HOME/.ssh/identity to any untrusted host ! On your central host, execute the commands (in a bash/bourne shell, and with "ssh-agent -s" in backticks):
You can then ssh/scp without typing the passphrase again, until you exit the current shell. |
![]() | Warning |
---|---|
On Solaris, the PATH environment variable on the remote host (where you build or deploy) may get set according to /etc/default/su, which may be different from what you would expect (noted by S. Bailey). |
Options --xor-code, --base1, --base2 are needed for consistency across multiple runs of configure. This is not important for client/server interaction, but for verification of e-mails/log files written by the client (if you make use of these additional logging facilities).
The deployed client is compiled to retrieve the database and the configuration file from the server. It will not work (except for initialization of the database) with database/configuration files stored on the client side. When invoked for file system checking, the deployed client will expect the server running on the host specified by --loghost, which by default is set to the local host on which deploy.sh is executed (surprise, surprise ...).
If you have properly used the options --clients and --client-files, you just need to send SIGHUP to the server after deploying a client, and everything is ready on the server side.
If you want to start the client immediately after deployment (normally, it would be started after the first reboot by the installed init script), then you need to add a command at the bottom of profiles/os-machine/bootscript (i.e. the shell script that modifies the remote host system configuration to make samhain start when booting).
Note that when this script is run, the server is not yet ready for serving the database and config file to the client (they are not uploaded to the server yet), therefore you must use at to start the client with some delay (example for SuSE Linux): echo /sbin/init.d/samhain start | at now + 1hour
To add support for another system type, just create a subdirectory named profiles/architecture/ in the source tree, and figure out appropriate files configopts, samhainrc, and bootscript. Note that the layout of the run level directories (with scripts to start/stop services when booting) is usually different for any two different Linux distros.
<<< Previous | Home | Next >>> |
Packing the executable | Building an RPM |