Beat the AIX Security Expert gotchas

Make friends with your AIXPert

The AIX Security Expert (AIXPert) makes implementing security a breeze, but it does have some traps for the uninitiated. Once you're aware of them, AIXPert is a natural choice for security hardening. So, if you want to secure your system without leaving yourself locked out in the rain, this article is for you.

Getting to know the AIX Security Expert

Develop skills on this topic

This content is part of a progressive knowledge path for advancing your skills. See AIX security: Learn the basics

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.

Safety warning (it is a security article, after all)

First, a warning. This article isn't intended to be a substitute for the available documentation. AIXPert was enhanced in AIX version 6.1, and some excellent resources are available for this great security tool. See Resources for links to many of them, such as those covering the various interfaces you can use, the names and locations of config files, and the command documentation. What I'm sharing in this article is my own experience in securing several AIX systems and the bumps I hit along the way.

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.

Resolution

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's XML files

AIXPert stores all of its settings in XML format. Several predefined levels of security allow you to enable all the security settings using a single command. If you want to drill down farther, you can use the Advanced menu in the GUI. You can also tailor the security rules you want by creating your own XML file.

Once you have a security policy in XML format, you can apply it using aixpert -f appliedaixpert.xml. You can also copy your security policy XML file across to other AIX systems and apply the same consistent rules throughout your organisation.

Resolution

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 undo.

Resolution

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.

Resolution

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 aixpert 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 compliance using 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.

Resolution

If you want the High security settings, run the aixpert 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.

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into AIX and Unix on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=AIX and UNIX
ArticleID=647404
ArticleTitle=Beat the AIX Security Expert gotchas
publish-date=04192011