Getting to know the AIX Security Expert
The AIX Security Expert—AIXPert, for short—combines more than 300 security settings under a single point of control. That makes securing your IBM® AIX® LPAR—or even hundreds of LPARs—simple. So easy, in fact, that when I first ran it on a test LPAR, I managed to lock myself out completely! (I never intended my system to be that secure.) Here's your chance to learn from my mistakes.
Once you get a feel for AIXPert's use of XML config files for its security scripts, you'll see that the tool is a smart and simple way of hardening your AIX system. You can implement high security with a single command. If you want to drill down, you can. AIXPert is granular enough to let you tailor rules to suit your needs. You can choose which rules you want to enable or disable. You can even set up your own rules. AIXPert also provides an Undo option, which lets you roll back your security changes in one step.
Here is my list of the AIXPert gotchas that got me. Don't say I didn't warn you:
- AIXPert needs to apply security before it can check security.
- AIXPert can't undo what it hasn't done.
- Undo has some exceptions.
- AIXPert doesn't run automatically.
- Sarbanes Oxley (SOX) Act Control Objectives for Information and Related Technologies (COBIT) settings don't imply high-security settings.
Gotcha 1: AIXPert needs to apply security before it can check it
AIXPert has an option that allows you to check the security settings
aixpert -c) against a previously applied set of rules.
If you haven't implemented that set of rules first using AIXPert, the tool can't
check the security of your system. So, if you've started locking down security
yourself—for example, by editing files, setting password rules, and so
on—the AIXPert security check won't work.
The reason is simple: AIXPert needs to work against its own baseline of applied settings, stored in a file called /etc/security/aixpert/core/appliedaixpert.xml. Without that baseline, the check option reports the error shown in Listing 1.
Listing 1. Checking security before setting it
# aixpert -c -l d File /etc/security/aixpert/core/appliedaixpert.xml does not exist
The file the check option is looking for contains all of the security settings you have applied via AIXPert.
Before you use AIXPert to check security, you need to set security using AIXPert. The list of rules you have applied is contained in the appliedaixpert.xml file. This file is created when you implement security using any of the AIXPert interfaces.
In Listing 2, you can see how to implement the default
level of security using the
aixpert command. The
last two lines of the output are also shown, indicating how many rules were
processed and the number of rules that passed and failed.
Listing 2. Apply the default level of security
# aixpert -l default # Processedrules=117 Passedrules=110 Failedrules=7 Level=DLS # Input file=/etc/security/aixpert/core/aixpertall.xml
Now, there is a baseline file called appliedaixpert.xml, as you can see in Listing 3.
Listing 3. Baseline file appliedaixpert.xml
# cd /etc/security/aixpert/core # ls -l appliedaixpert.xml -rw-r--r-- 1 root system 109237 Oct 07 07:40 appliedaixpert.xml
Running the check option using
aixpert -c should now
work. This check function reports the number of rules processed and how many passed or failed.
Gotcha 2: AIXPert can't undo what it hasn't done
One of the great features of AIXPert is that it can easily back out the security settings that it has applied. When you apply rules successfully, the corresponding Undo action rules are written to the undo.xml file. That's a pretty clever back-out plan, if you need to reverse your security changes. If you decide to bypass AIXPert and lock down some settings yourself, the Undo action rules don't get written to that undo.xml file, so AIXPert can't back them out.
AIXPert provides a single, consistent security configuration that is easy to replicate across multiple systems. The appliedaixpert.xml file allows you to have all your security settings in a single file, and the undo.xml file allows you to reverse them (with some exceptions—see Gotcha 3).
To secure your AIX system, you may need to implement hundreds of security settings. That's a high-risk task if you're doing them one at a time, and it could take hours to change on a single LPAR and even longer to undo. With all that security hardening work to do, it's far smarter, simpler, and safer to leave security hardening to the AIXPert.
Gotcha 3: The Undo option has some exceptions
The Undo option in AIXPert (
aixpert -u) reverses the
security changes made using AIXPert, but there are a few actions that you can't
Forewarned is forearmed, and it's important to be aware of the few exceptions to the Undo option. They include:
- Checking password, user, and group definitions for High, Medium, and Low security levels
- Changes to the login banner
- Removal of the guest account
These and the other settings that you can't undo using the AIXPert Undo option are outlined in the AIX Version 6 Advanced Security Redbook (see Resources for a link).
Gotcha 4: AIXPert doesn't run automatically
If you've been administering AIX systems for a while, you might expect that editing a configuration file (such as resolv.conf or sendmail.cf) would be enough for the change to take effect—at least after refreshing a daemon or, at the very most, following the next reboot. With AIXPert, there is no daemon. If you decide to edit the config file, you may be surprised to see that the security rules in it aren't applied, even after a reboot.
After you have added, deleted, or changed the rules in the XML file to a state
you're happy with, you need to apply these rules using
aixpert -f followed by a file name, as in the
example in Listing 4.
Listing 4. Apply security settings
# aixpert -f appliedaixpert.xml
AIXPert only applies the security rules when you want it to. If you were to
break a rule yourself—which, as the systems administrator, you are
entitled to do—you wouldn't want the
command to undo it without your knowledge. For example, if you opened
Telnet or FTP temporarily, it would be frustrating to have it disabled a moment
later by some overzealous security daemon.
If you wanted to, you could set up a
cron job to
enforce the rules periodically. Or, you may prefer simply to report your system
aixpert -c instead. That way, you
can decide which rules have been broken since the last time you applied
AIXPert, and then implement them again, if you want to.
Gotcha 5: SOX COBIT settings don't include high security
There are several levels of security in AIXPert—from AIX Default through Low, Medium, High, and Advanced. There's also SOX COBIT, which applies SOX COBIT Best Practices Security (SCBPS).
Now, you may think (as I did) that if you apply the SOX COBIT rules, your system's locked down, with all the high-level security rules in place. That's not the case. When you apply the AIXPert settings for SOX COBIT, you implement the SCBPS options for password policy enforcement, security violations and activity report, malicious software detection and correction, and firewall setup. As important as these are, they don't include all the security settings that you might want to apply by selecting High security, for example.
If you want the High security settings, run the
command with the High level first using
aixpert -l high,
and then apply SOX COBIT settings with
aixpert -l sox-cobit.
Hardening made easy
The AIX Security Expert really provides a simple, quick, and comprehensive way of applying security standards. It has several easy interfaces that allow you to apply a security level to your AIX system with a single command. It also allows you to customize your security via the XML configuration files and the command line.
Once you realize that AIXPert leaves you in control, you can apply security that is robust and consistent. You'll see what a time saver this security tool is for you—as long as the gotchas don't get you.
- Ken Milberg has an excellent overview of the AIX Security Expert in his developerWorks article Using AIX Security Expert (December 2008).
- The AIXPert hints and tips wiki shows the different interfaces you can use when setting security. It also lists the AIXPert rules, taken from /usr/security/aixpert/core/aixpertall.xml.
- Documentation on the commands, files, and settings that AIXPert uses is available at the IBM Infocenter.
- For a detailed outline of the security enhancements in AIX 6 along with practical examples, see the Redbook AIX V6 Advanced Security Features Introduction and Configuration.
- AIX and UNIX developerWorks zone: The AIX and UNIX zone provides a wealth of information relating to all aspects of AIX systems administration and expanding your UNIX skills.
- New to AIX and UNIX? Visit the New to AIX and UNIX page to learn more.
- Technology bookstore: Browse the technology bookstore for books on this and other technical topics.
- Check out my AIX blog on IBM developerWorks. It has lots of tips and practical examples for AIX administrators, and has tips for beginners as well as some more advanced topics. AIX Down Under.
- Follow me on Twitter and keep up with my blog updates.
- Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.
- Follow developerWorks on Twitter.
- Follow developerWorks on Twitter.
- Participate in developerWorks blogs and get involved in the developerWorks community.
- Get involved in the My developerWorks community.
- Participate in the AIX and UNIX® forums:
Dig deeper into AIX and Unix on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.