Security Considerations

(NOTE: Some of the techniques shown or described on this page--marked in purple--require new features in the latest official PIKT 1.19.0 release (pikt-current.tar.gz) that are unavailable in any previous version.)

Finally, security. PIKT client machines entertain piktc requests from the root account (typically) on the master control machine only. This implies that the master control machine should be secure, ideally inaccessible to ordinary users (or accessible only to trusted users). You should try to keep the identify of your master machine secret if at all possible (also the RPCPRGNUM (as registered in /etc/rpc) and system port number (using '../configure ... --enable-rpcprtnum=XXX ...', and as registered in /etc/services) that you compiled into the PIKT binaries).

PIKT master-slave, client-server communications rely on a four-tier security mechanism involving (1) host authentication, (2) secret key authentication, (3) service access rights, and (4) server-client callback.

In PIKT.conf, which functions roughly like a .rhosts or .shosts file, you set various access parameters (e.g., uid, gid, master, domain, master_address, etc.) and service rights (e.g., all_services, kill_service, install_service, etc.). By careful and judicious use of these settings alone, you can achieve a level of security sufficient in many situations.

As an option, you can use secret key authentication to prove the master's identity to the slave. For now, PIKT uses symmetric private key encryption/decryption of the authentication/session key. Public key encryption will be added sometime in the future.

We have selected the Blowfish cipher for our symmetric key encryption/decryption. Blowfish is reputed to be fast, and our PIKT implementation bears that out. Blowfish was also straightforward and relatively easy to implement. We do plan to offer alternative ciphers where demanded and as time permits.

Needless to say, you should take every precaution to keep your private_key secret. For example, if you store private_key in PIKT.conf, you should apply 600 or 400 permissions, and apply equally tight access rights on the PIKT etcdir (where PIKT.conf resides) and all parent directories. When you need to update your PIKT.conf files with a revised private_key (or if you store the key in a stand-alone etcdir/private_key file), use scp or some other secure method for distributing those files. Once you have the private_key established and PIKT encryption activated everywhere, you may of course manage secure installation of your PIKT.conf and/or etcdir/private_key like you would any other system file by way of, e.g., 'piktc -i +F PIKT.conf' or 'piktc -i +F private_key'. Note that the new private_key won't take effect until you restart the piktc_svc daemons, either manually or via 'piktc -R'.

If one managed to crack any system in the PIKT domain, one would have access to all common secrets. To solve this problem, you may use per-slave uid, gid, data_encryption_type, auth_encryption_type, and private_key settings. See the keys.conf section of this Reference for more details.

For a more detailed description of PIKT's secret key authentication scheme, see the piktc_svc section of this Reference.

For the OSes that support it, PIKT optionally employs server-client callback for even greater security. Please see the piktc_svc section of this Reference for more details.

For file installs, file fetches (to diff against the central configuration), and command executions, you can optionally encrypt all such data traffic between master and slave. For this purpose, too, we use the Blowfish cipher. Note that each and every service request uses its own separate "session key". If you install five different files, for example, five separate data encryption keys are used (same as the key used for secret key authentication).

Even with encryption/decryption enabled and all the extra security overhead, PIKT master-slave, client-server communications are still surprisingly fast.

piktc and piktc_svc do complete service request logging, and piktc_svc marks denied requests as "ERROR". It is not difficult to set up log monitoring scripts (and scripts to monitor the monitoring scripts, etc.) to spot attempted security break-ins. Remember that you can log to syslog and special logs, and dump to a printer, besides sending out e-mail alerts. Scripts can also call pagers in security emergencies. You can even have a monitoring script kill the local piktc_svc under suspicious circumstances.

If you have turned on auto_syslog in PIKT.conf, you can route all log messages to a central loghost in real time. It would not be too difficult to match legitimate piktc service log entries with client-side piktc_svc log entries, thereby identifying anomalous service requests. Moreover, you could run this also in real time, and send out pages, dump to a printer, etc., if illegitimate activity is detected.

In firewalled environments, you should bind piktc_svc to a specific system port (by default 850, but you should change this to some other unused port number). See the distribution INSTALL file on how to do this. Assuming you have blocked all unused system ports at the firewall, you should unblock the designated PIKT port using the appropriate firewall rules. In any event, note that you still need to run the portmapper, also unblock it at the firewall.

In the future, we might have piktc_svc run optionally via inetd, enabling all the tcpd protections and loggings, if you are using that excellent utility.

Through some combination of the above-described methods, we believe that you can make your PIKT setup as secure as necessary.

You can use PIKT for security in at least the following six ways:

As just a centrally directed scheduler. Have piktd invoke your preferred security tools according to the schedules in piktd.conf.
The above, plus have PIKT manage other security tools' config files (the inevitable per-machine and per-OS customizations using #if's).
All of the above, plus use PIKT #ifdef's to activate/deactivate different security tools as conditions warrant.
All of the above, plus use PIKT to handle your security log file analysis and incident reporting.
All of the above, plus employ PIKT alarms and data objects as supplements to the standard tools. (For example, have PIKT do things that other tools don't, or don't do conveniently or well; add paging capabilities to tools that lack them; etc.)
Use PIKT exclusively (or almost exclusively; PIKT will never replace crack!).

We submit that there are no good or widely known solutions out there for points one, two, and three above.

As for point four, there are good solutions out there already to manage your security log files, but PIKT should better them due to its more powerful and flexible built-in scripting language (Pikt).

As for point five, extending one tool requires you to learn Perl, another to get down-and-dirty with the Bourne shell, while five others require you to learn five different cryptic and proprietary command languages. Learn those languages and modify those tools on their own terms where that makes the most sense, but when sensible add PIKT where the others leave off.

Point six, in spite of its great virtue of involving just one system and command language to learn and use, we wouldn't dare claim that PIKT can outdo every other security tool out there.

The optimum solution probably lies somewhere around point five.

Doubtless, no one can disagree that:

Security should be a daily, ongoing concern.
It should be systematic.
It should be flexible.
It should be easy to manage.

These are areas where PIKT excels. At the very least, PIKT is a general framework on which to build your security efforts.

Please see the sample configurations, where we use the power of PIKT to implement these security principles.

1st page