RFC-NG Howto
(version 1.0.1)
About this
document
This Howto, written by Claudio
`sekko` Panichi, is released under the terms
of GNU GENERAL PUBLIC LICENSE (Version 2)
The author is NOT responsible
for any damage that can result from the
incorrect use of RFC and/or documentation
1. WHAT'S RFC
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.
---------------------------------------------------------------------
2. REQUIREMENTES
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! ;-)
---------------------------------------------------------------------
3. INSTALLATION AND CONFIGURATION
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.
---------------------------------------------------------------------
4. USAGE
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! ;-)
---------------------------------------------------------------------
5. RFC & CRON
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:
[1]
50 04 * * * /<path>/<to>/<rfc>/rfc-ng.sh run
[2]
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.
---------------------------------------------------------------------
6. HIGHER SECURITY
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.
---------------------------------------------------------------------
7. LINKS
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