NAME
picalib - Set of PICA helper scripts and configuration files
DESCRIPTION
PICALib is a set of PICA-related files to help in several system
administration tasks, like filesystem integrity checks, package update
automation, backups, NTP configuration, anti-virus protection, etc. It
is a collection of "modules", documented independently.
ADMIN DOMAINS
Most of the alarms included use the concept of "admindomains". An
admindomain is a group of administratively related hosts. The idea is
that within PICA only hosts in the same admindomain will interact with
each other.
For example, the NTP module generates a configuration where hosts
belonging to the ntpservers synchronize with each other, But you don’t
want servers from client (or network) A synchronizing with servers from
client B. The answer is to define different admindomains for each
client and include the clients’ hosts in that group.
This is done in a very simple way. Including all the hosts in a group
and defining the variable "admindomain" for that group:
hostgroup clientA {
members { host1, host2, host3 }
vars {
admindomain = 'clientA';
}
}
DNS - CONFIGURATION FOR THE DNS SERVICE
This module can be used to generate a basic DNS configuration. It can
generate a normal or split DNS configuration. Split DNS means that you
will have two different views of the domain, depending on the source IP
address of the query. This is very usefull in firewalls because you can
give different info to the internal and external networks.
This modules is related to the DHCP module in the way that it will
allow dynamic DNS updates from the DHCP server if you set $ddns in the
DHCP module. This updates will be cryptographically authenticated.
· Variables shared with the DHCP module
domainname
DNS domain name
netprefix
Network prefix (3 bytes). If you have network "192.168.1.0/24"
it will be 192.168.1.
· Variables for the basic configuration:
forwarders
List of dns forwarders to use (optional)
rndckey
key to sign the control commands send with rndc. Generate it
with dns-keygen
dnsmasters
list of dns master servers. Only needed if you have slave
servers
distzonefiles
set this variable if you want to distribute the zone files
using pica. If you do, you must create the zone files with the
apropriate name (see below) in the PICA server. If you don’t
use this feature, you have to create those files in the DNS
server
· Additional variables for splitdns:
splitdns
Set this variable if you want to generate a splitdns
configuration
dnsextmasters
list of master servers for the external zone
· Zone files
This modules assumes the zone files will be named:
${domainname}.db
for the zone
${domainname}-ext.db
for the EXTERNAL zone
${netprefix}.db
for the reverse zone
You can use example.com.db and 192.168.1.db as a model to create
your zone file
DHCP - CONFIGURATION FOR THE DHCP SERVICE
This module generates a simple DHCP configuration. It basically creates
a dynamic range for the given network prefix.
The variables you should configure are:
domainname
DNS domain name for the clients
netprefix
IP network prefix (3 bytes). Ex. 192.168.1
router
the default gateway for this network
dnsservers
list of DNS servers for this network
nbservers
NetBIOS name server (Could be Samba or a WINS server)
The following options are needed only if you want the DHCP server to
dynamically update the DNS zone for the given domain.
ddns
Do we want ddns?
dhcpkey
a key allowed to send updates to the server (generate with dns-
keygen). The server must be configured to allow updates signed with
this key. The PICA group DNS does this automagically ;)
NOTES
This group only works with DHCPv3!!! If you want to use an older
version, you can’t use the DDNS feature...
The DHCP server and the DDNS server MUST be the same host. If you don’t
like this restriction change the primary 127.0.0.1 entries in
dhcpd.conf...
NTP - CONFIGURATION FOR THE NTP SERVICE
This module generates a very simple NTP configuration. It assumes two
kinds of NTP servers in an organization:
ntpservers
Main NTP servers in the admingroup. They will be synchronized to
various public stratum-1 servers (they will be stratum-2). The
will also act as NTP peers (all the servers in this group will
synchronize with each other). You will need AT LEAST ONE server in
this group for each admingroup.
ntpclients
NTP clients. They will be synchronized to all the ntpservers in the
same admingroup. This is why you need at least one "ntpserver"
host.
Backup - BACKUP SERVICE
This module generates a client/server configuration of Amanda. It uses
two hostgroups:
bckservers
The tape server
bckclients
The clients we want to backup
The clients will be configured to only allow connections from the tape
server.
The backup will be configured to do full backups on fridays. On
thursday the system will check if everything is OK for friday’s backup.
If this configuration suits your needs, you will only need to label the
tapes...
INSTALLATION NOTES
To install the Backup service ypou first have to set all needed
variables (see sample etc/hosts.conf). These variables are:
amcfg
The amanda configuration name. Amanda uses this name to be refer to
a backup configuration. You can have many backup configurations in
the same server as long as this name is different
amorg
Organization name. Amanda will put this in the subject of any email
report it sends. Put something to quickly identify this
configuration
ammailto
email address where amanda will send backup reports
amtapecycle
Number of tapes we have for rotation
amsrvip & amsrvfqdn
IP and full name of the tape server. To setup the access
restrictions
amdisklist
disklist file to use, relative to the Backup dir in picalib. This
variable exists because you probably want different disklist files
for each backup group
AntiVirus - CONFIGURATION FOR THE ANTIVIRUS SERVICE
This Antivirus service includes two alarms to automatically scan
filesystems and update the virus databases. It also integrates cleanly
with PostFix.
This alarm needs the following software installed:
· Kaspersky Antivirus for Linux
· avcheck
Info - INFO DIRECTORY FOR PICA
This module contains some misc. files, as a proposed MOTD and webpage
for PICA-administered hosts.
Snort - CONFIGURATION FOR THE SNORT SERVICE
Snort is an excelent Inrusion Detection System (IDS). This module
installs Snort in all hosts included in the "snort" group.
After installing this module you will need to edit the
/etc/snort/snort.conf file to set the device and "HOME_NET"
The script oinkmaster is used to automatically check for new snort
rules. The /etc/snort directory must be owned by the user that runs
oinkmaster (shoud NOT be root)
This alarm needs the following software installed:
· Snort
· SnortSnarf
· oinkmaster
FireWall - CONFIGURATION FOR THE FIREWALL SERVICE
This group includes a simple but powerful iptables based firewall. It
can protect the host where it is running and/or an internal network. It
can also do destination NAT to allow access to internal hosts using
private IP addresses.
See firewall.conf for configuration.
PIFIA - PICA FRAMEWORK FOR INTEGRATED ALARMS
This directory contains the PIFIA files. To use PIFIA based alarms in
the target hosts, you shoud "#include" in the toplevel of your
objects.conf the pifia.conf file located in the include directory.
genalarms - GENERAL ALARMS
This directory contains alarms to make critical checks on servers:
DfChk
Checks filesystem usage and notifies if a given threshold (default
90%) is reached
PermsChk
Check permissions and owner on a list of files and directories.
This list is read from an object file (Perms.obj). If the
"proactive" flag is set to 1, it will correct the anomalous
situations
ProcChk
Checks if critical services are running. This services are read
from an object file (Procs.obj). If the "proactive flag is set to
1, it will correct the anomalous situations
TripWire - CONFIGURATION AND ALARM FILES FOR TRIPWIRE INTEGRITY CHECKER
To Install this group in a host
1. Add the host to the hostgroup tripwire
2. Install the tripwire group in the host:
pica -iv +F triwire +H host
3. Install the tripwire software on the host. If you already installed
APTChk you can just do:
pica -xv +F "APTChk -p -v" +H host
4. You need to initialize Tripwire in the host. To do it run:
/etc/tripwire/twinstall
It will ask you passwords for the site and local keys. The site key
is used to sign/encryt the config and policy files. The local key
is used to sign the tripwire database and reports. It’s supposed to
have only one site key for the whole organization and a local key
for each server, but this group doesn’t currently support this
configuration. So you will have a site and local key pair for each
host.
5. Initialize the tripwire database:
tripwire --init
That’s it, TWChk will check your filesystem integrity every night.
If it finds any change, it will notify you. If the changes are
authorized you should update the tripwire database with:
1. Run twupdate in the host or:
pica -xv +F twupdate +H host
in the PICA master (this way you can update all servers)
2. It will open en editor (vi) with the last tripwire report to
let you specify what changes to update. If you want to update
all of them just save and exit.
3. It will then ask you for the password of the local key to
update the
tripwire database
Also, anytime you change the policy file (twpol.cfg) you will have
to sign it on every host. twpol.txt will remind you anytime you
install it:
# pica -iv +F twpol.txt +H tripwire
twpol -> /etc/tripwire/twpol.txt 0.0 600 0
***********************************************
NOTE: Remember to run twadmin -m P twpol.txt!!!
***********************************************
You can sign it on many servers at once running:
pica -xv +F "twadmin -m P twpol.txt" +H host1 host2 ...
APTChk - APTCHECK ALARMS
This module contains the files and alarms used to make sure all the
servers have the latest critical packages installed (either by apt-get
or apt-rpm).
For this service we use apt-rpm (apt-get if the machine is in the
"debian" group) and a simple alarm that runs nightly. This alarm
updates the RPM database from a central apt-rpm repository and can
install any needed update.
We have the RPM repository in a central host where we mirror redhat
updates nightly. We also have some directories containing aditional RPM
packages.
We also distribute a file containing the critical packages needed by
every server, so the alarm can check and install it as needed.
APT-RPM REPOSITORY SERVER
These are the steps to setup an APT-RPM Repository server.
1. Setup a redhat mirror...
You will need at least the distribution binaries and the updates
section. I recommend using the URLGet alarm to make mirrors using
rsync. It’s MUCH faster than FTP or HTTP. With the default
configuration, the RedHat mirror generates the following tree:
$localdir/redhat
7.2/
i386/ -> RH 7.2 binary mirror
RedHat/
RPMS -> RH 7.2 binary RPM packages
SRPMS -> RH 7.2 source packages
updates/i386 -> RH 7.2 updates RPM Packages
SRPMS -> RH 7.2 updates source Packages
2. Setup de APT-RPM repository
APT needs a repository tree with the following structure:
$aptrepdir/
7.2/
SRPMS.main -> RedHat 7.2 distro SRPMS packages
SRPMS.updates -> RedHat 7.2 updates SRPMS packages
SRPMS.custom -> Custom SRPMS for RH 7.2
i386/
RPMS.main -> RedHat 7.2 distro binary RPMS packages
RPMS.updates -> RedHat 7.2 updates binary RPMS packages
RPMS.custom -> Custom binary RPMS for RH 7.2
base/ -> Directory where APT saves the databases
Since the RedHat tree has a different structure, I usually mirror
RedHat with their structure and creates the APT structure creating
symlinks.
This symlinks should be RELATIVE if this is going to be accesible
via anonymous FTP.
3. Generate the APT databases
The alarm APTRep will generate the APT repositories for you. You
just have to define the repositories and modules in the variable
$aptreps.
This alarm will be run nightly, but you can force APT repository
regeneration with:
pica -xv +F "APTRep -v" +H aptserver
AUTHOR
PICALib and its documentation was written by Miguel Armas del Rio
<kuko@maarmas.com>. It was converted to POD by Esteban Manchado
Velazquez <zoso@demiurgo.org>.
POD ERRORS
Hey! The above document had some coding errors, which are explained
below:
Around line 469:
You forgot a ’=back’ before ’=head1’