Organizing System Security
PIKT is an excellent tool for organizing system security. You can run security monitoring scripts written in the Pikt script language (or some other language); configure, schedule, and run other security tools; routinely scan security log files (filtering out the noise and only reporting the interesting stuff, or perhaps issuing a page); and so on.
Here is an example Pikt script to report checksum differences for certain critical system files, which would perhaps be indicative of hacker activity:
ChecksumDifference
init
status active
level critical
task "Report checksum differences for certain critical
system files."
input file "=checksums_obj"
// dat $csauth 1 // not used
// dat $szauth 2 // not used
dat $name 3
rule
if ! -e $name
output mail "$name not found!"
else
set $actual = $checksum(5, $name) // MD5 cksum
if $inlin ne $actual
output mail "$name checksums differ!"
output mail " auth: $inlin"
output mail " actual: $actual"
fi
endif
If you group this script with other scripts in the Security alerts collection in the piktmaster alerts.cfg file, you might install those alerts to all systems using the command:
# piktc -iv +A Security +H all [or: ... -H down sick]The ChecksumDifference script might send alert e-mail like the following:
PIKT ALERT
Sat Oct 25 14:31:05 2003
cologne
CRITICAL:
ChecksumDifference
Report checksum differences for certain critical system files.
/bin/login checksums differ!
auth: 63605c254a6a9928b8075963c951dbbf 29144 /bin/login
actual: 938a4ca4a6dd7b8665faa4cde6a83f73 29356 /bin/login
ChecksumDifference makes reference to the =checksums_obj macro, which resolves to the name of the Checksums.obj file. Here is a portion of that file:
890d9f416d29291a41a3f952a7358373 363712 /pikt/bin/pikt 28d110c55407285c1223adc801a602f4 435260 /pikt/bin/piktc 41c7ebd9c17959836b268ab331e51bb3 74356 /pikt/bin/piktd c557598d115d0bc3c5178bc023bda72d 107152 /pikt/bin/piktc_svc ee63902deabd52d1939cdf51f374692c 11116 /pikt/bin/pikts 05778150ac6be9ae93b76a41533b71f8 16513 /pikt/bin/piktx f451dabcb9ceef0e4e87787fa52cd2a4 115207 /pikt/bin/pikth 96298d99457ba610e49e3f94052ce7f0 42980 /sbin/arp 543bd6e6cbc86ced89cfa03ac7727e42 205544 /usr/bin/awk 8ae35b6674f94b932750388fbea1217b 11576 /usr/bin/basename 660cbf8925f42e7dc96f0d5d4ec39838 15224 /bin/cat 5c3fdcaf07874fb8ff59a46286d39687 18680 /bin/chgrp 80aca26874544ca02fdbdfd3ab5de112 18552 /bin/chmod b731208ed852f072c3d0a17f5ff565c6 20596 /bin/chown ... 63605c254a6a9928b8075963c951dbbf 29144 /bin/login ...Checksums.obj sources from the security_objects.cfg file, a portion of which follows:
////////////////////////////////////////////////////////////////////////// // // security_objects.cfg // ////////////////////////////////////////////////////////////////////////// [... other objects omitted ...] ////////////////////////////////////////////////////////////////////////// Checksums #verbatim <objects/adm/checksums_piktbin_objects.cfg> #if suse # include <objects/adm/checksums_suse_linux_objects.cfg> #endif #if redat # include <objects/adm/checksums_redhat_linux_objects.cfg> #endif ... ////////////////////////////////////////////////////////////////////////// [... other objects omitted ...] //////////////////////////////////////////////////////////////////////////The checksums_piktbin_objects.cfg file specifies MD5 checksums and file sizes for the PIKT binary files. It might contain:
890d9f416d29291a41a3f952a7358373 363712 /pikt/bin/pikt 28d110c55407285c1223adc801a602f4 435260 /pikt/bin/piktc 41c7ebd9c17959836b268ab331e51bb3 74356 /pikt/bin/piktd c557598d115d0bc3c5178bc023bda72d 107152 /pikt/bin/piktc_svc ee63902deabd52d1939cdf51f374692c 11116 /pikt/bin/pikts 05778150ac6be9ae93b76a41533b71f8 16513 /pikt/bin/piktx f451dabcb9ceef0e4e87787fa52cd2a4 115207 /pikt/bin/pikthThe checksums_suse_linux_objects.cfg file specifies MD5 checksums and file sizes for important SuSE Linux system files. It might contain:
////////////////////////////////////////////////////////////////////////// // // checksums_suse_linux_objects.cfg // ////////////////////////////////////////////////////////////////////////// #if suse #indent 96298d99457ba610e49e3f94052ce7f0 42980 /sbin/arp 543bd6e6cbc86ced89cfa03ac7727e42 205544 /usr/bin/awk 8ae35b6674f94b932750388fbea1217b 11576 /usr/bin/basename 660cbf8925f42e7dc96f0d5d4ec39838 15224 /bin/cat 5c3fdcaf07874fb8ff59a46286d39687 18680 /bin/chgrp 80aca26874544ca02fdbdfd3ab5de112 18552 /bin/chmod b731208ed852f072c3d0a17f5ff565c6 20596 /bin/chown ... 63605c254a6a9928b8075963c951dbbf 29144 /bin/login ... #unindent #endif // suse //////////////////////////////////////////////////////////////////////////Why isolate the PIKT programs in their own separate #include file? Well, on our development systems the PIKT program files change much more frequently than the standard system files. For this and other reasons, we note their checksums and file sizes separately.
Note that we #include the checksums_suse_linux_objects.cfg (and other) file(s), and instead use #verbatim to include contents of the checksums_piktbin_objects.cfg file. #verbatim tells the piktc preprocessor to include a file "as is" (ignoring potential PIKT comment markings, for example, "//", and suppressing any potential PIKT macro expansions) and to supply an implicit indent (because the preprocessor recognizes stanza content by its indentation). So, the content lines in checksums_suse_linux_objects.cfg require an explicit #indent directive while the lines in checksums_piktbin_objects.cfg do not.
mkchecksums.pkt is a simple Pikt script you might use to generate your PIKT checksums specification files.
On the piktmaster system, we would install Checksums.obj file to each PIKT slave system with the command:
# piktc -iv +O Checksums +H all [or: ... -H down sick]Note that if a hacker were to change one or more of the system binaries on a PIKT slave system--also change the checksums and file sizes in the slave system's Checksums.obj file--you could detect those changes by diffing
# piktc -fv +O Checksums +H all [or: ... +O all ...]and/or by comparing checksums
# piktc -m5v +O Checksums +H all [or: ... +O all ...]These two commands compare the checksums and file sizes between their specifications on the piktmaster (in the objects.cfg files) and on the slave (in the Checksums.obj file). This is different from the ChecksumDifference script above, which compares the checksums and file sizes (in the Checksums.obj file) on the slave with the actual binary file checksums and file sizes on the slave.
Note that you could do the above piktc diff and checksum compare operations manually, but you would probably want to do them automatically and regularly from within another PIKT monitoring script. Following is one such script.
#if piktmaster
PiktcChecksumWarning // any checksum diffs reported here signal
// changes made by a sysadmin outside the
// PIKT system, else possible hacker
// tampering
// reports +A +O +P only; we now report +F in a
// separate PiktcFilesChecksumWarning
init
status active
level debug
task "Checksum all +A +O +P PIKT files against the
central configuration"
input proc "=rm =piktdir/etc/piktc.lock 2>/dev/null;
=piktc -m5v +A all +O all +P all -H down sick"
rule // skip noise and blank lines
if $inlin =~ "checksummed|checksumming file"
|| $inlin eq ""
next
fi
rule // determine current sys
if $inlin =~ "processing ([[:alnum:]]+)\\.\\.\\."
set $sys = $1
next
fi
rule // output sys header
=incr(#diff[$sys])
if #diff[$sys] == 1
output mail =newline
output mail "processing $sys..."
output log "=piktcchecksum_log"
"processing $sys..."
fi
rule // output 'checksums differ' line
output mail $inlin
output log "=piktcchecksum_log" $inlin
#endif // piktmaster
Suppose you want to run the Security scripts, including ChecksumDifference, several times daily on mission-critical systems, while just once daily is enough for all other systems. You might specify this in your alerts.cfg file:
Security
#if missioncritical
timing 30 6-22/4 * * *
#else
timing 30 6 * * *
#endif
...
This says to run the Security alerts every four hours, from 6:30 AM to 10:30 PM, on the mission-critical systems, and at 6:30 only on all other systems.
Now, what if you had another script, or objects file, with a much more comprehensive list of critical system files (including all system commands, libraries, etc.)? Such a script might take much longer to run and consume significant system resources. Under ordinary circumstances, you might want to run that script just once weekly. If you have special reason to be worried, you might want to run it daily. If your systems are currently under attack or you have reason to be exceptionally paranoid (normal paranoia is good), you might want to run it several times daily. There are a number of ways you could configure this. Here is one possible way:
MoreSecurity
#ifdef paranoid
# if missioncritical
timing 30 6-22/2 * * *
# else
timing 30 6-22/4 * * *
# endif
#elsifdef worried
# if missioncritical
timing 30 6-22/4 * * *
# else
timing 30 6 * * *
# endif
#elsedef
# if missioncritical
timing 30 * * * 1,3,5
# else
timing 30 6 * * 1
# endif
#endifdef
...
alarms
...
ChecksumDifferenceComprehensive
...
In words, these specifications say: in paranoid mode, run the special security scripts several times daily everywhere; in worried mode, run the scripts several times daily on mission-critical systems, and just once every morning on all other systems; otherwise (in "normal" security mode), run the special security scripts on Monday, Wednesday, and Friday morning on the mission-critical systems, and just on Monday morning on all other systems.
You might instead group ChecksumDifferenceComprehensive with the "ordinary" security scripts in this way:
Security
#if missioncritical
timing 30 6-22/4 * * *
#else
timing 30 6 * * *
#endif
...
alarms
...
#ifdef paranoid
ChecksumDifferenceExhaustive // checksum
// *everything*
#elsifdef worried
ChecksumDifferenceComprehensive // checksum
// most
// everything
#elsedef
ChecksumDifference // checksum just the
// most critical files
#endifdef
...
The possibilities for arranging and scheduling this are almost endless.
Checksum differences is just one among many, many different things you can have PIKT monitor, and security monitoring is just one among many different tasks you can assign to PIKT. Aside from writing and executing Pikt security scripts and configuring and scheduling security tools, generally speaking 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' configuration 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!).
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.
 prev page |
1st page | next page  |
