Provided by: picalib_0.1.5-2ubuntu1_all bug

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 Río
       <kuko@maarmas.com>.  It was converted to POD by Esteban Manchado
       Velázquez <zoso@demiurgo.org>.