RFC-NG Howto (version 1.0.1)

About this document
This Howto, written by Claudio `sekko` Panichi, is released under the terms
The author is NOT responsible for any damage that can result from the
incorrect use of RFC and/or documentation


Let's suppose that you are a SysAdmin and you have just installed
the OperativeSystem on 20 or more new servers. Once you think that
all is configured, you put these servers on the network and users
will start to work with them. Since that moment, you must be sure
that any server will not be hacked, so you'll check the logs and
you'll apply any new patch to the software. But what does it happen
if someone could, for example:

    * change some foundamental binaries like grep, ls, ps etc.
    * create a new user or group
    * change the UID of a particular user (for example he could
      set `lpd` UID to 0 once he have hacked the system, and he
      will login as lpd and work as root on that host!)
    * change the SUID/SGID to any executable so that he can run
      program with very high privileges
    * alter the log files

and you don't have a particular way to find out what happened?
If you chose to use a FileSystem-Integrety-Checker (FSC) like AFICK,
AIDE or Integrit he should remember how it works:

    * Once the system is installed, you have to create an initial
      database that contains many informations about each file
      you wishes to monitor: size, modification time, md5 etc.
    * Every day you will run (via `cron`, maybe) the same FSC that
      will compare the initial-database with the current system
      and will notify with an email (or with a specific log-file)
      any modifications to the system.
    * If FSC finds any modification and you are sure that these
      modifications are dued to system upgrade, you will update
      the initial-database; otherwise the system's hacked!

It is clear that the initial-database is a very critical point, since
an hacker could remove or (even worse) modify it. In that case, you
will not be able to know what happened and you will not take any
countermeasure. The hacker's playing on your system, and you cannot
see that...

RFC (Remote Filesystem Checker) is a set of scripts that aims to help
system administrators run a filesystem checker (like tripwire, AIDE,
etc.) from a "master-node" to several "slave-nodes" using ssh, scp,
sudo, and few other common shell commands.

If the Master is a stand-alone machine with no service running on it
(in other words: it's just a network client), none can login or gain
access on it through the network. Since all databases, executables
and configuration-files are stored on this Master-node, you can be
quite sure that the results from FSC are reliable.

It's interesting to observe that RFC will not run as root and does
not require root access on master-node and slave-nodes. RFC will use
ssh/scp to login on remote nodes and copy any file from/to these
nodes. To avoid root login, RFC requires `sudo` on remote hosts.

It's very simple to understand how RFC works. An account for a user
that will run RFC must be created, both on master and slave nodes.
You don't need to use the same account on master and slave, and the
default username will be `rfc` on them both.
The Master node have the RFC console to add, remove, configure a
particolar slave-node. Once you've added all your slave-nodes, you
have to initialize their databases but RFC provide a function to do
it automatically. At the end, you'll put a line in `rfc`-user crontab
to run RFC everyday and you will receive an email to one or more
account that you'll set during the initial configuration (see below).

RFC uses scp to move executable, configuration files and databases
from master-node to slave-nodes, and ssh to run the choosen FSC (and
other things that we'll see later) on remote nodes. Once RFC finishes
its work, scp is used to move back all of the files on master-node,
and no files will be left on slave-nodes. The program `sudo` is
required to run the FSC.

To avoid that RFC hangs on a particular slave-node (that could be
down or unreachable), a preliminar test is performed to check if ssh-server
is active on any host. If it's not true, the host will be skipped
and an alert will be put into the log that the SysAdmin will receive
as report.


RFC does require nothing more than bash2 and few other programs, very
common on any POSIX system. A list of these requirements follows.

    * Master node:
        - awk
        - bash2
        - chmod
        - diff
        - find
        - grep
        - kill
        - mail
        - sort
        - scp2 (client)
        - ssh2 (client)
        - ssh-keygen
        - wc

    * Slave nodes:
        - bash2
        - chgrp
        - chmod
        - chown
        - perl (if you chose AFICK and/or SUID/SGID checks)
        - sudo
        - ssh2 (server, with rsa/dsa key auth enabled)

Not so much, as you can see! ;-)


Very very simple! Do the following:

1) as root, create a simple account for the user that will run RFC.
   Let me suppose that this user is called `rfc`.

2) login as `rfc` and unzip the RFC tarball with
    tar xvzf rfc-ng.X.X.X.tar.gz

3) Once unzipped, you'll see a directory named `rfc-ng-X.X.X`. Change
   into this folder and with your preferred editor open rfc-ng.sh to
   set the right value of RFC_DIR. You have to put the absolute path
   to rfc-ng.sh in this variable, and do not touch anything else!

4) Finally, open rfc-ng.conf end edit the all the field (if needed)
   untill you read "Don't touch the following lines!!!". It should be
   very easy: pay attention to typo-errors and to some particular
   field like MAIL_ADDRESS, PROC and TIMEOUT because RFC will not
   warn you if this values are wrong.

Maybe you have to chmod 700 rfc-ng.sh and chmod 600 rfc-ng.conf to
run RFC.


Once you've configured RFC, try to run the script without argument
so you'll see the `help` message:

#                     USAGE:                                                                 #
#                                                                                                    #
# ssh-key-gen                             (create new ssh keys)          #
# ssh-key-del                              (delete the ssh keys)             #
# set-perm                                  (set right permissions)         #
# node-add                                  (add a node to RFC list)       #
# node-chk <node>                   (check <node>)                     #
# node-update <node>             (update <node> - ask)         #
# node-force-update <node>   (update <node> - force)      #
# node-remove <node>            (remove <node> - ask)        #
# node-force-remove <node>  (remove <node> - force)     #
# mass-chk                                 (check all nodes)                  #
# mass-update                           (update all nodes)                #
# mass-remove                          (remove all nodes)                #
# list-nodes                                 (list all RFC nodes)              #
# run                                           (check all and send report) #
# mail [<address>]                   (send a report)                     #
# chk-config                               (check RFC config)               #
# version                                    (show RFC version)              #
#                                                                                                  #

There are some steps you have to do in a particular order:

1) Run `./rfc-ng.sh ssh-key-gen` to create ssh public/private keys

2) Run `./rfc-ng.sh set-perm` to set right permissions to RFC files

3) Now run `./rfc-ng.sh chk-config` and see if all is right

Once you did it all, you're ready to add all you slave-nodes to RFC.
It should be clear from the help-screen what you have to do. Just
follow the instructions that will appear during each operation and
live happy! ;-)


Once you're sure that RFC works fine, you may automate the checks.
This is obviously done via crond, so the master-node can run RFC
during the night (for example) when other nodes are not so busy.
It's a simple matter. On master-node, login as the user that runs
RFC and type "crontab -e" to edit the cron table. It will appear an
editor with the current table opened, so just add one of the
following lines:

50 04 * * * /<path>/<to>/<rfc>/rfc-ng.sh run

50 04 * * * /<path>/<to>/<rfc>/rfc-ng.sh run > /dev/null 2>&1

They do the same thing: at 4:50-AM RFC will be executed. You can
change this setting to whatever you prefer!
The difference between [1] and [2] is that the first will send an
email to the user that runs RFC, while [2] will not send any report
generated by crond itself. But both of them will send an email to
the address that you specified in rfc-ng.conf, obviusly.


For higher security, you should keep in mind the following points:

    * There's no real need for the user that runs RFC to have a
      password! You can always use "su -" so change user.
    * When you setup /etc/sudoers, you can specify the hostname
      or IP-address the user running RFC can cannect from. Try
      "man sudo" for more details.
    * Do not run any service on master node, not even ssh-server
      since RFC uses the client only.
    * Try to use monolithic-kernel, without module support so
      that it will not be easy to install a rootkit.
    * Use PaX (kernel patch) to avoid many attacks based on dirty
      buffer overflow.
    * Use grsecurity (a kernel patch that includes PaX too) to
      hide processes or files, and to have a very strong MAC/RBAC
      system on your node.


Some useful links. For more information, you can visit the following
sites. Some are for RFC, and others are for "higher-security":

AFICK - http://afick.sourceforge.net
AIDE - http://www.cs.tut.fi/~rammer/aide.html
GrSecurity - http://www.grsecurity.org
INTEGRIT - http://integrit.sourceforge.net
OPENSSH - http://www.openssh.org
PaX http://pageexec.virtualave.net
RFC project page - http://sourceforge.net/projects/rfc
SUDO - http://www.courtesan.com/sudo
SUID.PL - http://www.vmunix.com/~gabor/programming.html

    -- Claudio `sekko` Panichi
       November 17, 2005