picalib(7) 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 <[email protected]>. It was converted to POD by Esteban Manchado Velazquez <[email protected]>.

POD ERRORS

Hey! The above document had some coding errors, which are explained below:
Around line 469:
You forgot a '=back' before '=head1'

LAST SEARCHED