One of the simplest things which we are asked to do constantly
is to disable dangerous programs as bugs are discovered. CERT
security warnings frequently warn about programs with flaws
which can compromise a system. In cfengine, disabling a file
means renaming it to *.cf-disabled and setting its permission to 400.
Although this is a trivial matter, the fact that it is automated means
that cfengine is checking for this all the time. As long as a host is
up and running (connected to the network or not) cfengine will be
ensuring the named file is not present.
Another issue is to replace standard vendor programs with drop-in replacements.
For example, most admins would like to replace their vendor sendmail
with the latest update from Eric Allman's site. One way to do this
is to compile the new sendmail into a special directory, separate
from vendor files and then to symbolically link the new program into
place.
The exclamation marks mean (by analogy with the csh) that existing
file objects should be replaced by links to the named files. Again
the integrity of these links is tested every time cfengine runs.
If the object /usr/lib/sendmail is not a link to the named file, the old
file is moved and a link is made. If the link is okay, nothing happens.
After putting the new sendmail in place, you will need to
make sure that the restricted shell configuration is in order.
#
# Sendmail, restricted shell needs these links
#
solaris::
# Most of these will only be run on the MailHost
# but flist (procmail) is run during sending...
/usr/adm/sm.bin/vacation -> /usr/ucb/vacation
/usr/adm/sm.bin/flist -> /home/listmgr/.bin/flist
linux::
/usr/adm/sm.bin/vacation -> /usr/bin/vacation
Link management is a particularly useful feature of cfengine.
By putting links (actually all system modifications) into the
cfengine configuration and never doing anything by hand,
you build up a system which is robust to reinstallation. If you
lose your host, you just have to run cfengine once or twice
to reconstruct it.
Of course, the fundamental tenet of security is to be able to
restrict privilege to resources. We therefore need to check the permissions on
files. For instance, a recent CERT advisory warned of problems with
some free unix mount commands which were setuid root. If we suppose
there is a group of hosts called `securehosts' which we don't need to worry
about, then we could remove the setuid bits on all other hosts as
follows:
One area where cfengine excels over other tools is in its ascii file
editing abilities. Editing textfiles in a non-destructive way is such
an important operation that having used it you will wonder how you
every managed without it! Here are some simple but real examples
of how file editing can be used.
editfiles:
# sun4, who are they kidding?
{ /etc/hosts.equiv
HashCommentLinesContaining "+"
}
#
# CERT security patch for vold vulnerability
#
sunos_5_4::
{ /etc/rmmount.conf
HashCommentLinesContaining "action cdrom"
HashCommentLinesContaining "action floppy"
}
TCP wrapper configuration can be managed easily by maintaining
a pair of master files on a trusted host. Files of the form
# /etc/hosts.allow (exceptions)
#
# Public services
sendmail: ALL
in.ftpd: ALL
sshd: ALL
# Private services
in.fingerd: .example.org LOCAL
in.cfingerd: .example.org LOCAL
sshdfwd-X11: .example.org LOCAL
# Portmapper has to use IP series
portmap: 128.39.89. 128.39.74. 128.39.75.
editfiles:
{ /etc/inet/inetd.conf
# Make sure we're using tcp wrappers
ReplaceAll "/usr/sbin/in.ftpd" With "/local/sbin/tcpd"
ReplaceAll "/usr/sbin/in.telnetd" With "/local/sbin/tcpd"
ReplaceAll "/usr/sbin/in.rshd" With "/local/sbin/tcpd"
ReplaceAll "/usr/sbin/in.rlogind" With "/local/sbin/tcpd"
processes:
"inetd" signal=hup
The services which we do not need should be removed altogether.
There's no sense in tempting fate:
Please take a moment to fill out
this visitor survey You can help support this site by
visiting the advertisers that sponsor it! (only once each, though)
