Good Grief—What Can Be Done About Identity Theft at the *NIX Level?

What does the SecuringAIX blog, or any OS, have to do with concerns regarding identity theft, such as those incidents showing up in Dutch news? BTW: The botnet in the news in Holland is called “Pobelka,” which is Russian for "money laundering." I expect similar stories are being reported in the rest of the world, although the Dutch press will have us believe the Dutch region is "special" as it is one of the most densely integrated IP infrastructures. In short, recent events have me questioning myself: What impact does this have on security measures at an OS level.

This returns to the same concerns of an earlier post—"Are You Sure About Your AIX Security?"—when I wrote about the avalanche of security breaches in user systems (i.e., “desktop” and other botnet targets).

Modern criminal attacks don’t focus on attacking the OS directly or on deleting files. Instead, they focus more on being clandestine—staying as long as they can and harvesting all kinds of information. Remember “analytics?” Well, my assumption is criminals are tech savvy enough to know that business analytics can also be applied to information harvested from PCs.

OK, so now I have made myself nervous (read “scared”), and I still struggle with my Charlie Brown reaction—"my stomach hurts." But I am back to my initial question, “What does, or can, this mean in terms of OS security?”

The short-term impossibilities: in-depth knowledge of all of the applications on my system. Application mechanisms are also at risk—more so than the OS mechanisms—because the identity information harvested is more likely used, short term, to gain access to an application as a recognized user. The potential short-term approaches include throwing some technology at it (read: nothing I want to do because I don’t have a clear enough definition of what I want to, or think I can, accomplish).

 "My Stomach Still Hurts!"—Where to Start?

I'll be honest with you—and myself. There are no simple answers. However, I am getting more "nervous" about the widespread use of sudo as the mechanism/technology for controlling access to root. The “opponents” know of the growing dependency on this tool as well as its precise weak points. I assume they buy, install and study intricate—yet easy—ways to break through the protection a technology is supposed to provide.

(Note: I also think controlling access to root is the wrong approach to *NIX security. Instead, I want—literally—to control access.)

For now, I sit with my question and think about the expected requirements for some sort of role-based—there you have it again—access control as well as additional “real” requirements for auditing. As I come up with ideas—ideally that span technologies—I will shall share them with you. And, less ideally, I’ll talk about technology-based approaches in coming blog posts and replies to comments.

My request? Share your questions and insights via comments to SecuringAIX!

Have a safe and secure day!

AIX Hardening 101

Roughly eight years ago, in AIX V5.3 ML5, IBM introduced a tool known as AIX Security Expert or aixpert. The goal was simple—provide a simple “push-button” or “1-2-3” method to harden AIX—releasing the administrator from the task of creating and updating customized hardening scripts.

The initial release only had three levels (four if you count default): low, medium and high. Later, a way to customize aixpert was added. Later still, a new level, sox-cobit, was added.

The command aixpert is part of bos.security.rte, so it’s always there for you to try out.

Still using your own hardening scripts?

Here’s a simple way to compare how well your scripts stack up to aixpert levels. First, choose your level of comparison: low, medium or high. For SOX, I recommend PowerSC, because it includes an extended SOX-COBIT XML file. Then, run the tests. For the appliedaixpert.xml file, the test can be ignored if you’ve never used aixpert.

AIXPERT CHECK as Test Drive

So, to test drive your AIX hardening with no configuration changes made to your system, use:

# [[ -e /etc/security/aixpert/core/appliedaixpert.xml ]] /

   && mv /etc/security/aixpert/core/appliedaixpert.xml /etc/security/aixpert/core/appliedaixpert.xml.save

# aixpert -l high|medium|low|default|sox-cobit -n -o /etc/security/aixpert/core/appliedaixpert.xml

# aixpert –c

# rm /etc/security/aixpert/core/appliedaixpert.xml

# [[ -e /etc/security/aixpert/core/appliedaixpert.xml.save ]] \

   && mv  /etc/security/aixpert/core/appliedaixpert.xml.save  /etc/security/aixpert/core/appliedaixpert.xml

# more /etc/security/aixpert/check_report.txt

During the test drive, let it tell you what it finds wrong (note: wrong means different). If the level you choose thinks 4 is the right number and you get a different number (3 or 5, for example) it will say it failed. In other words, there might be some false negatives.

Reasons to Adopt aixpert

1. Consider how many days you would need to get your hardening scripts ready before—and after—the next visit from the IT auditor.

2. Instead of spending all that time maintaining scripts you can inform the IT auditor, “My hardening scripts are from IBM.”

3. It’s really, really easy.

4. Starting with AIX V6.1, you can manage and apply the settings via the Lightweight Directory Access Protocol (LDAP) model!

Combining audit and syslog

Hello all. It has been much too long since I last wrote on SecuringAIX. My apologies. This has not been for lack of something to write about—I have been hoping to have a bit more to say.

So, a short blog to get me started again in 2013!

While visiting a customer, I was asked about combining audit with syslog. The basic steps are easy, and I’ll show them here. The harder part is getting the classes defined properly so you don’t get swamped by too many messages.

The basic step is to edit /etc/security/audit/config and set streammode = on, and give it an improved streamcmds file. As an example, an excerpt of my config file looks like this:

start:

        binmode = on

        streammode = on

bin:

        trail = /audit/trail

        bin1 = /audit/bin1

        bin2 = /audit/bin2

        binsize = 102400

        cmds = /etc/security/audit/bincmds

        freespace = 65536

        backuppath = /audit

        backupsize = 0

        bincompact = off

 stream:

        cmds = /etc/security/audit/streams.004

 

The streams.004 file then looks like this:

auditstream -m -c general | tee -a /audit/general.bin | auditselect -e "result==FAIL && command!=java" | auditpr -v | logger -p local1.warn -t audit &

auditstream -m -c files      >>/audit/files.bin &

auditstream -m -c tcpip      >>/audit/tcpip.bin &

Note that every command in streamcmds starts as auditstream, and all run in the background. If they do not, then audit start does not start.

In addition, each auditstream command is one line (no \ escapes at the end of a line for formatting). Otherwise the command audit start hangs or returns with an error.

A sample output in syslog file is:

Jan 30 23:07:03 x054 local1:warn|warning audit: FILE_Open       root     FAIL        Wed Jan 30 23:07:03 2013 date         

Jan 30 23:07:03 x054 local1:warn|warning audit:         flags: 0 mode: 0 fd: 3 filename /usr/share/lib/zoneinfo//posixrules

Jan 30 23:07:03 x054 local1:warn|warning audit: FILE_Stat       root     FAIL        Wed Jan 30 23:07:03 2013 ksh                             

Jan 30 23:07:03 x054 local1:warn|warning audit:         cmd: 10 filename: /var/log/blockip/noact.log

Jan 30 23:07:03 x054 local1:warn|warning audit: FILE_Stat       michael  FAIL        Wed Jan 30 23:07:03 2013 ksh                             

Jan 30 23:07:03 x054 local1:warn|warning audit:         cmd: 0 filename: /usr/bin/audit

Jan 30 23:07:03 x054 local1:warn|warning audit: FILE_Stat       michael  FAIL        Wed Jan 30 23:07:03 2013 ksh                             

Jan 30 23:07:03 x054 local1:warn|warning audit:         cmd: 0 filename: /opt/bin/audit

Jan 30 23:07:03 x054 local1:warn|warning audit: FILE_Stat       michael  FAIL        Wed Jan 30 23:07:03 2013 ksh                             

Jan 30 23:07:03 x054 local1:warn|warning audit:         cmd: 0 filename: /etc/audit

Jan 30 23:13:17 x054 auth|security:info sshd[8323294]: Bad protocol version identification 'abcd' from 192.168.129.121

The last entry is from the application sshd writing to the auth syslog rather than local1.

Are You Compliant, in Control, or Neither?

Finally, THE IBM Redbook publication I have been waiting for has appeared in draft (Redpaper) form. This Redbook is about Security (yes, capital S) Management and also about PowerSC. 

Today I’ll be short, RE: PowerSC.

 For no additional charge, you have access to the PowerSC standard edition when you have licensed the AIX Enterprise Edition (AIXEE) bundle.

If you do not have the AIXEE bundle, there’s a limited-time special offer—30 percent discount off the IBM one-time charge on licensing PowerSC.

Back to the Redbook draft, which is titled: “Managing Security and Compliance in Cloud or Virtualized Data Centers Using IBM PowerSC.” Obviously, it covers a lot of information about PowerSC. But what I hope you will look at is the first chapter wherein the authors:

• Explain Security Drivers, a business-driven Security Framework
• Introduce IBM’s (new) Security Blueprint, and
• Close with a short discussion on Security Compliance and Management

In the last topic on Security Compliance and Management, they ask the questions:

Do you know the difference between being “in compliance" and "in control?” Which is more important? And, if you are neither "in compliance" nor "in control," which one should you focus on?

Drum roll! Their answer to the last question is: "in control.”

I hope you download and read the Redbook draft. I have already read several things where I wish I had been clever enough to phrase it so eloquently.

And, in following blog posts, besides talking about PowerSC, I also want to take up RBAC for AIX as a means to be more "in control.”

Using RBAC With Scripts

I have been working on a set of tools, known as AIX Security Assessment Tool (ASAT), and want it to be able to run without requiring root privileges to execute it. I am not really decided about the best way to approach this—so I am asking for comments on a skeleton procedure.

RBAC SCRIPT TEST Skeleton
Step A: Create a test file, chmod to 0, and try to copy it, etc. This fails of course.

$ ls -l >xxx
$ chmod 0 xxx
$ cp xxx yyy
cp: xxx: The file access permissions do not allow the specified action.

Step B: Write a shell script to copy the file—this also fails.

$ echo "#!/usr/bin/ksh\ncp xxx yyy && ls -l yyy" > test.ksh
$ chmod u+x test.ksh
$ ./test.ksh
cp: xxx: The file access permissions do not allow the specified action.

Step C: Add privileges to the script and execute. Note: For this example, I am using a special authorization.

I employ (ALLOW_OWNER) rather than creating an authorization and assigning it to a role. Second, I am assigning privilege PV_ROOT—which is much more than is needed. Normal usage dictates using tracepriv to determine the least privileges needed to use a command.

$ su
# setsecattr -c accessauths=ALLOW_OWNER innateprivs=PV_ROOT secflags=FSF_EPS `pwd`/test.ksh
# setkst
# exit
$ ./test.ksh
----------    1 michael  staff          6534 Nov 22 04:26 yyy

Step D: Clean up when finished.

$ su
# setsecattr -c accessauths= innateprivs= secflags= `pwd`/test.ksh
# setkst
# exit
$ ./test.ksh
cp: xxx: The file access permissions do not allow the specified action.

Comments
I am looking for feedback. I have never used sudo, so I am curious how something like this would be done using sudo. Extra info: It's the command /usr/bin/ksh that is actually getting the privileges—so if you shell escape out of a command started by this shell, you still have those privileges.

As a start, care will be needed to prevent shell escapes (can be done for some commands, e.g., vi, by redefining the SHELL variable before starting any other commands). I have already seen that using Ctrl-Z does not leave you in an elevated shell (you return to your previous shell status).

Don’t bother commenting about my use of PV_ROOT in the example above—that is just because I am lazy. Do think about the dangers of using any of ALLOW_USER, ALLOW_GROUP, ALLOW_ALL.

I’m looking forward to your comments. I shall try to respond to all in a timely manner.