As usual, I’m late to the party. I was at the Power Systems Technical University in San Antonio several years ago (an awesome venue), and there was a session on the new AIXPert feature of AIX 6.1 (later back-ported to 5.3). At the time I though it was clunky and wasn’t too excited about it.
It’s really just a bunch of pre-packaged shell scripts, that are defined in an XML file you really need to manage manually (the horror). You run the master aixpert command and specify what XML file you want. You can go with AIX Defaults, Low, Medium, High, and SOX (if you’re into that kind of thing). When you run aixpert, it applies whatever settings are associated with the level you selected. Here is where I usually yawn. It’s just not that exciting. Everyone pretty much does that with a script or text file or some corporate documentation (probably written by someone without a clue, E&Y I’m looking at you). Yes, there are a couple of ways to get to a GUI, but it’s really more manageable for me with the commandline.
The bit that gets tedious is that no one definition is going to fit any one shop. So you have to export the standard definitions to a custom XML file and open it up and hack it by hand. Systems like XML, I don’t really are to read it all day long. But, it’s not that difficult, here’s an example:
<AIXPertEntry name="cust_udp_recvspace" function="udp_recvspace">
<AIXPertRuleType type="LLS"/>
<AIXPertDescription>Network option udp_recvspace: Set network option udp_recvspace's value to 655360</AIXPertDescription>
<AIXPertPrereqList>bos.rte.security,bos.rte.shell,bos.rte.ILS,bos.net.tcp.client,bos.rte.commands,bos.rte.date</AIXPertPrereqList>
<AIXPertCommand>/etc/security/aixpert/bin/ntwkopts</AIXPertCommand>
<AIXPertArgs>udp_recvspace=655360 s cust_udp_recvspace</AIXPertArgs>
<AIXPertGroup>Tune network options</AIXPertGroup>
</AIXPertEntry>
Nothing too fancy there. It’s mostly fluff, the PrereqList, Command, and Args options are the important ones, the rest of more for the user than anything else. When you apply that XML, the system runs the shell script which sets the appropriate network option. It’s all fairly simple.
The cool part is that most of the things set with aixpert can also be checked with aixpert. When you apply an XML file, aixpert saves the rules that applied to /etc/security/aixpert/core/appliedaixpert.xml. If I modify that setting and run “aixpert -c”, aixpert parses the appliedaixpert.xml file and checks things out. This is what I get:
# aixpert -c
do_action(): rule(cust_udp_recvspace_CA6BE6C2) : failed.
Processedrules=66 Passedrules=65 Failedrules=1 Level=AllRules
Input file=/etc/security/aixpert/core/appliedaixpert.xml
To set the world right again, you just re-apply your XML file. I found a minor issue here. I’ve had to remove the /etc/security/aixpert/core/appliedaixpert.xml file before setting a new one. You can get the same rule in there repeatedly, why IBM doesn’t offer a commandline switch to do that I don’t know.
Another cool thing, you can Undo the changes applied by the built-in aixpert rules. When aixpert applies a setting, it writes an undo rule to /etc/security/aixpert/core/undo.xml. Then, running “aixpert -u” will undo what you’ve already done. I would probably purge that once in a while too so that you can recover to a known good state.
So, just wrap a dirt-simple cron script around it to notify when something goes wrong… Something like this:
#!/usr/bin/perl
$EMAIL_ADDRESS = "user\@domain.net";
@TEMP = `hostname`;
$HOSTNAME = $TEMP[0];
chomp($HOSTNAME);
$MAIL_FROM_ADDR="aixpert@$HOSTNAME";
@OUTPUT = `/usr/sbin/aixpert -c 2>&1`;
@REPORT = grep(/^Processedrules.*/, @OUTPUT);
$REPORT[0] =~ s/\s+/=/g;
($null, $PROCESSED ,$null, $PASSED, $null, $FAILED, $null, $LEVEL) = split(/=/, $REPORT[0]);
if ( $FAILED > 0 ) {
open (MAIL, "| /usr/sbin/sendmail -t ");
select (MAIL);
print "Mime-Version: 1.0\n";
print "Content-type: text/html; charset=\"iso-8859-1\"\n";
print "From: $mail_from_addr\n";
print "To: $EMAIL_ADDRESS <$EMAIL_ADDRESS>\n";
print "Subject: Aixpert $HOSTNAME: $FAILED test FAILED\n";
print "<html><head></head><body>\n";
print "<pre>\n";
print "@OUTPUT";
print MAIL "</pre>\n"; print MAIL "</body></html>\n";
$~ = "STDOUT";
close (MAIL);
exit 1;
}
exit 0;
That should keep the auditors happy. There are enough basic security settings in the default XML files that with a little tweaking you can hit all or very nearly all of your security audit queries.
That’s all well and good, as far as that goes, but what really made me like aixpert is that it gives you a very simple framework to apply your own settings, and make sure those settings are correct. If you distribute an XML file and a few scripts around your enterprise, you can ensure that those settings are standardized across hosts too.
Here’s a simple script to make sure the attributes of your vscsi devices are correct:
#!/bin/perl
@ADAPTERS = `lsdev -c adapter -Sa | grep -E "^vscsi" | awk '{ print \$1 }'`;
$REPORT = $ENV{'AIXPERT_CHECK_REPORT'};
%ATTRIBUTES = ("vscsi_err_recov", "fast_fail",
"vscsi_path_to", 30 );
if ( $REPORT == 1 ) {
for (@ADAPTERS) {
chomp($_);
$ADAPT = $_;
@TEMP = `lsattr -El $ADAPT | awk '{ print \$1, \$2}'`;
for (@TEMP) {
($ATTR, $VALUE) = split(/\s+/, $_);
if ( $VALUE != $ATTRIBUTES{$ATTR} && $ATTRIBUTES{$ATTR} ) {
print "$ADAPT attribute $ATTR is $VALUE, should be $ATTRIBUTES{$ATTR}\n";
$FAIL++;
}
}
}
if ( $FAIL ) {
exit 1;
}
}else {
for (@ADAPTERS) {
chomp($_);
$ADAPT = $_;
@TEMP = `lsattr -El $ADAPT | awk '{ print \$1, \$2}'`;
for (@TEMP) {
($ATTR, $VALUE) = split(/\s+/, $_);
if ( $VALUE != $ATTRIBUTES{$ATTR} && $ATTRIBUTES{$ATTR} ) {
system("/usr/sbin/chdev -l $ADAPT -a $ATTR=$ATTRIBUTES{$ATTR} 2>&1 > /dev/null");
}
}
}
}
Using a script like this as a template, you can check and correct the value of any number of system attributes. Adding it to aixpert is a breeze, just add a stanza to your XML file:
<AIXPertEntry name="cust_vscsi_config" function="vscsi_config">
<AIXPertRuleType type="MLS"/>
<AIXPertDescription>Resets attributes of the vscsi devices</AIXPertDescription>
<AIXPertPrereqList></AIXPertPrereqList>
<AIXPertCommand>/etc/security/aixpert/custom/vscsi_config.pl</AIXPertCommand>
<AIXPertArgs>GENERIC</AIXPertArgs>
<AIXPertGroup>Custom Rules</AIXPertGroup>
</AIXPertEntry>
Once you decide to get into it, aixpert is a pretty nice little tool. There’s a great little movie created by Nigel Griffiths at the DeveloperWorks website to get you started too!
But, I still don’t care for System Director. 🙂