picalib - Set of PICA helper scripts and configuration files

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.

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';
     }
 }

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 CW$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 CW192.168.1.0/24 it will be CW192.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

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 ;)

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...

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.

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...

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

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

This module contains some misc. files, as a proposed MOTD and webpage for PICA-administered hosts.

Snort is an excelent Inrusion Detection System (IDS). This module installs Snort in all hosts included in the CWsnort group.

After installing this module you will need to edit the /etc/snort/snort.conf file to set the device and CWHOME_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

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.

This directory contains the PIFIA files. To use PIFIA based alarms in the target hosts, you shoud CW#include in the toplevel of your objects.conf the pifia.conf file located in the include directory.

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

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 ...

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 CWdebian 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.

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 CW$aptreps. This alarm will be run nightly, but you can force APT repository regeneration with:

   pica -xv +F "APTRep -v" +H aptserver

PICALib and its documentation was written by Miguel Armas del Río <kuko@maarmas.com>. It was converted to POD by Esteban Manchado Velázquez <zoso@demiurgo.org>.