Screenshots
Pakiti: A Patching Status Monitoring Tool |
Pakiti provides a monitoring and notification mechanism to check the patching status of systems.
NEW Pakiti v3 will be available soon, see further information here.
Pakiti in current version 2.1.5 is using a client/server model, where clients and servers are exchanging information using HTTP(S).
Once installed on a client host, Pakiti will send every night the list of installed packages to the relevant Pakiti Server(s). After the client sends the list of installed packages, Pakiti server compares the versions against versions which Pakiti server obtains from packages repositories (ordinary packages repositories maintained by Linux distribution provider) and OVAL definitions from MITRE. Optionally client reports back the packages which should be upgraded, security updates are specially marked.
Pakiti uses a Web page provides a list of the registered systems and the list of the pending patches for them. This helps the system administrator keeping multiples machines up-to-date and prevent unpatched machines to be kept silently on the network.
In addition, a security module in Pakiti is able to distinguish security fixes from normal bug fixes/product improvement for all Linux distributions which has packages repositories based on rpm (yum) or dpkg (apt) and has different location for normal and security updates.
For Linux distributions based on the RedHat, Pakiti is able to check packages against CVEs (http://cve.mitre.org). In the next release Linux distros based on SuSE will be also checked. Debian based distros are also a candidate, but Debian currently does not provide approved data in CVE format.
Information about older versions:
The packages (RPM) and sources are available here.
It is also possible to access the Pakiti CVS server hosted on Sourceforge here.
Pakiti 2.1.5 has been released on 12/02/2013:
The Pakiti Client is a small bash script, which will gather list of actually installed packages and report them to the central Pakiti Server.
It simply gather packages installed on the host using rpm -qa or dpkg-query
respectively.
Pakiti DOES NOT INSTALL ANY UPDATED PACKAGES.
Pakiti currently uses two methods how to find out if the package is not up-to-date:
Pakiti server once a day downloads information from the vendors repositories and stores them. Location of the repositories can be found on the clients machines, for example on Debian systems in /etc/apt/sources.list, on RedHat systems in /etc/yum.repos.d/. When the client machine reports the list of installed packages Pakiti server checks whether the version is older then that one in the repository.
Second method is actually applicable only on systems based on RedHat. Once a day Pakiti server downloads OVAL definitions for the RedHat systems. Packages' versions from Linux systems based on RedHat are also check against these information.
Of course, the tool you choose MUST be first properly configured.The Pakiti client send an HTTP message to the server containing the list of installed packages.
It is recommended to use HTTPS to authenticate the remote server and to send information through a secure channel. To use HTTPS, your Pakiti configuration file MUST contains the full path or directory where is the certificate of the CA who issued the Pakiti server's certificate. In this way, the Pakiti client will be able to check the Pakiti server's certificate. Of course, to use HTTPS, your Pakiti server MUST be HTTPS enabled.
There are two ways how to install the Pakiti client. After installing the pakiti-client-manual-*.rpm package all files are extracted into /usr/share/doc/pakiti-client-2/ and you have to do manual installation described in the README file. The second option with the package pakiti-client-*.rpm do complete installation. Pakiti client script is installed into /usr/sbin/pakiti2-client, the configuration file is located in /etc/pakiti2/pakiti2-client.conf and the cron script is installed into /etc/cron.daily/pakiti2-client-update.
There are two ways how to configure Pakiti client. You can directly edit Pakiti
client script pakiti2-client and set default values there, of
course you have to comment the variable CONF. Or you can use configuration file pakiti2-client.conf and copy it to the /etc/pakiti/ or specify -c
# Configuration file for Pakiti. # Pakiti servers, use space as delimiter # Exmaple: servers_name = pakiti1.server.com:443 pakiti2.server.com:8443 servers_name = pakiti1.server.com # URL of Pakiti script on the server, default /feed/ #server_url = /feed/ # CA Path, where is located certificate of the CA which issued SSL certificate for the Pakiti server, default /etc/ssl/certs #ca_certificate = /etc/ssl/certs # The client certificate and the key for the host authentication #host_cert = /etc/ssl/host.pem # Connection method: 'autodetect' (default) or 'curl' or 'openssl' or 'stdout' #connection_method = curl # OpenSSL binary, with the options you like, by default openssl is located by # command which #openssl_path = /usr/bin/openssl # Curl binary, with the options you like, by default curl is located by # command which #curl_path = /usr/bin/curl # Put something small that can identify your site/host/team, without spaces. tag = TEST # Does the client should report back the list of packages needs upgrade? # (default 0 - off) # report = 0 # If the pakiti client works as a proxy. It can send results to the server on # behalf of other pakiti client. Pakiti client can produce results to the # stdout, these results can be passed to the proxy pakiti client over the stdin. # The host, which runs proxy pakiti client has to be listed in the Pakiti # server configuration file in section: trusted_proxy_clients # (default 0 - off) # is_proxy = 0 # If the host has more then one interface, it can be setup which is used for outgoing communication, # for example: eth0 or IP address # Warning: This option works only with curl connection method # (default "") # interface = # Prints statistics to the stdout about number of successful reports to the Pakiti servers # (default 0 - off) # server_rep_stats = 0
Pakiti client should be run at least once a day. There is prepared cron script in /usr/share/doc/pakiti-client-2/pakiti2-client.update.cron.daily:
# Wait for random time (0-240s), so we do not overload the server RANDOM_NUMBER=`od -An -N2 -d /dev/random` WAIT_TIME=`echo $(( 1+( $RANDOM_NUMBER )%(240-1) ))` sleep $WAIT_TIME # Run the client path to the pakiti2-client exit 0
# apt-get install httpd php5 mysql-server php-mysql mod_ssl pakiti-server
If some other dependency are needed, the packages should be available through your vendor. For more information about installing the client, please see the previous section.
Download the latest RPM and run:
# rpm -i pakiti-server-*.rpm
Configure MySQL to start at boot
# chkconfig --level 235 mysqld on
Start the mysqld service
# /etc/init.d/mysqld start
Change the MySQL root password
# /usr/bin/mysql mysql
~ update mysql.user set Password=PASSWORD('strong_root_password') where User='root' and Host='localhost';
~ flush privileges;
~ quit;
Create the pakiti database
# mysqladmin -u root -p create pakiti2
Fill the tables
# /usr/bin/mysql -u root -p pakiti2 < /usr/share/doc/pakiti-server-*/pakiti2.sql
You can use default configuration
# /usr/bin/mysql -u root -p pakiti2 < /usr/share/doc/pakiti-server-*/pakiti2_initial_configuration.sql
Create a Pakiti user
# /usr/bin/mysql -u root -p mysql ~ GRANT LOCK TABLES, SELECT,INSERT,UPDATE,DELETE ON pakiti2.* TO 'mysql_user'@'localhost' IDENTIFIED BY 'mysql_password'; ~ flush privileges; ~ quit;Of course, 'mysql_user' and 'mysql_password' are up to you.
It is *strongly* recommended to use HTTPS and client authentication. One way of doing this is to create a /etc/httpd/conf.d/pakiti.conf containing:
<VirtualHost 0.0.0.0:443> SSLEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP SSLCertificateKeyFile <YOUR_HOST_KEY_PATH> SSLCertificateFile <YOUR_HOST_CERTIFICATE_PATH> SSLCACertificatePath /etc/grid-security/certificates DocumentRoot /var/www/pakiti2/www/ ErrorLog logs/pakiti-error CustomLog logs/pakiti-access common Alias /feed "/var/www/pakiti2/www/feed" <Directory "/var/www/pakiti2/www/feed"> SSLRequireSSL Options -All AllowOverride None DirectoryIndex index.php </Directory> Alias /link "/var/www/pakiti2/www/link" <Directory "/var/www/pakiti2/www/link"> SSLRequireSSL Options +FollowSymLinks AllowOverride None Order allow,deny Allow from all DirectoryIndex index.php </Directory> <Directory "/var/www/pakiti2/www/pakiti"> # Restrict access to this directory by your own auth mech, authorization can be made by the Pakiti itself SSLRequireSSL Options +FollowSymLinks AllowOverride None Order allow,deny Allow from all DirectoryIndex index.php </Directory> </VirtualHost>
The top level configuration of the Pakiti server can be changed in /etc/pakiti2/pakiti2-server.conf
# Configuration file for the Pakiti webinterface. # Set the parameters for connecting to # the Pakiti database. [mysql] hostname = localhost dbname = pakiti2 username = mysql_user password = mysql_password [webinterface] # URL of your local Pakiti server url = https://pakiti.server.com title = My_Organization
Now, try to access web GUI of your Pakiti server. It everything is OK, you should see main page, where there are no hosts listed. Click the "Settings" link in the right-top corner.
RedHat OVAL Definitions
Provide URLs to the OVAL definitions. Then you can select which one will be checked once a day for the updates. It is useful to add all OVAL definitions, then manually run /var/www/pakiti2/scripts/process_oval_rh.php, this will fill Pakiti database with information from all OVAL definitions. Afterwards, for OVAL definitions which were actual in the past, you can uncheck "Check this source for updates", because old definitions are not updated any more, this will save Pakiti server resources.
Os Group Definitions
This section can be configured after all of your host (or the majority of them) report to the Pakiti server. Each host will report its OS name to the Pakiti server and in this section you can define OS groups. OS groups are used for repository definitions. Some package repositories are used by several versions of one OS, for example Debian 5.0, 5.0.1, 5.0.2 and 5.0.3 uses one repository. After Os groups are set up, we can define repositories.
Repositories Definitions
On the bottom of the page, there is a from with fields:
Above the form you can see the list of Oses which does not have assigned any repository. You should create corresponding Os groups and add to them these Oses, then you can add repositories for that Os groups.
Legend of the icons used on the Settings page:
There was an error during repository update.
Repository was updated successfully.
At least one host runs OS which is bounded to this repository.
There are no hosts which have installed OS bounded to this repository. The line is also highlighted.
CVE Tags
Some important CVEs can be tagged and then view in the CVE Tags report page. Usually we don't care of all CVEs, some has no impact on the infrastructure, but others describes really dangerous security issue, so we can tag that CVE and monitor occurence of that CVE on the machines on single report page. Is some administrator manually fix the issue and little bit change the version of the package, Pakiti is unable to detect, that the software is fixed. Therefore we can create an exception for the particular package version, that won't be shown in the reports.
Pakiti supports authorization. Edit config/config.php and set $enable_authz = 1;. Now you have to provide list of administrators in config/config.php:
# DNs of logins of the users, who can setup authz # Example for SSL AuthN: $admin_dns = array ( "/DC=cz/DC=cesnet-ca/O=Masaryk University/CN=xxx1", "/DC=cz/DC=cesnet-ca/O=Masaryk University/CN=xxx2" ); # Example for Basic AuthN" $admin_dns = array ( "user1", "user2" ); $admin_dns = array ( );Afterwards you can also specify other users, who will have access to certain domain. On the web GUI you can see ACL link in the right-bottom menu.
If $asynchronous_mode = 1; is set in the config/config.php Pakiti won't check the vulnerabilities when the host reporting, but only after manual run of the scripts/recalculate_vulnerabilities.php.
If your Pakiti server is behind the HTTP proxy, you can specify the proxy in config/config.php:
# Repository_updates and process_oval_rh access remote sites, you can setup proxy here # $web_proxy = "tcp://proxy.example.com:3128";
Pakiti client can also work as a proxy for other Pakiti clients. Set is_proxy = 1 in pakiti2-client.conf and add the hostname of the Pakiti proxy client in config/config.php:
# Array of the trusted proxy clients, that can send results on behalf of other pakiti clients # Example $trusted_proxy_clients = array ( "proxy1.ics.muni.cz", "proxy2.ics.muni.cz" ); $trusted_proxy_clients = array ( );
On every page you can add "tld=(list of TLDs separated by comma)" to the URL and the hostnames in the results will be filtered by provided TLDs.
For example: https://pakiti.server.com/hosts.php?tld=cz,de,uk
Only hosts from cz, de and uk will be listed.
This page is intended to help site admins to find at a glance outdated or missing locations for a specific package throughout their cluster. The list of found and available packages versions is listed at the beginning with
Next, the list of nodes with an outdated packages is displayed. The matching is done using the OS group id and the assigned repo. The current installed version is also displayed for verification purposes.
Last, the list of nodes where the considered package is not installed are displayed.In order to enable this page, set the variable $ext_pages_outdated = 1.
The Outdated/Missing packages page was made by Catalin Dumitrescu from Fermilab.