Posts tagged ·

security

·...

New AIX Password Restrictions

Comments Off

Question

In recent versions of AIX new password restrictions have been created.

Answer

New AIX Password Restrictions

As system administrators are asking for more restrictions on user account passwords, AIX has added new features to accommodate them.

Starting in AIX 7.1 (7100-00-00), AIX 6.1 TL 6 (6100-06-00), and VIOS 2.2 the following new password features have been added.

  • Disallow User Name In Password

If the existing attribute “dictionlist” is used in /etc/security/user to not allow new passwords that match words in a dictionary, the string $USER can be inserted into the dictionary file. After this, any user changing their password will not be allowed to use any form of their username in the password, in upper case, lower case, or mixed case.

For example user “root” could not use these passwords:
123root
rootabc
RooTabc

The typical dictionary on AIX is /usr/share/dict/words, which is included in the fileset “bos.data”. This fileset is not usually installed but can be added after the OS is installed.

  • Disallow A Pattern In The Password

Again, using the existing dictionlist attribute, a pattern consisting of a regular expression can be added to the dictionary file and thereby excluded as part of a password. This can be generalized by using the asterisk * as the first character, to differentiate between a pattern and a dictionary word.

For example the pattern *123 in the dictionary file will disallow any password containing the string “123″ anywhere in it.

  • New Password Parameters

New parameters have been added to /etc/security/user file to assist administrators in more finely tuning the passwords users can have.

minloweralpha
Defines the minimum number of lower case alphabetic characters in a new password.
Default: 0 (no minimum)
Range: 0 to 8

minupperalpha
Defines the minimum number of upper case alphabetic characters in a new password.
Default: 0 (no minimum)
Range: 0 to 8

mindigit
Defines the minimum number of digits in a new password.
Default: 0 (no minimum)
Range: 0 to 8

minspecialchar
Defines the minimum number of special characters in a new password.
Default: 0 (no minimum)
Range: 0 to 8

Comments Off

Auditing an Object

Comments Off

Question

How can I audit a specific command or file on AIX?

Cause

Need to know which user or process is executing a command or opening a file for READ or WRITE.

Answer

The following steps can be used to configure AIX Auditing to audit individual files (including commands) for READ, WRITE and/or EXEC access.

1) Make changes to audit config file to enable streammode auditing…

#vi /etc/security/audit/config

start:
binmode = off
streammode = on

With streammode, you will immediately get the output in text format. If you choose binmode, you will have to convert the data from binary to text before reading it (see Technote: AIX System Security Audit for more details -
http://www.aixmind.com/?p=2429 )

2) Confirm the following line is in /etc/security/audit/streamcmds file

/usr/sbin/auditstream | auditpr -v > /audit/stream.out &

Note that there is a “-v” after auditpr. The -v is not set by default, but it gives you more information. If you want to limit what events will be monitored you can also modify this
file to use the auditselect command, eg…

# vi /etc/security/audit/streamcmds

/usr/sbin/auditstream | /usr/sbin/auditselect -e “command!=cron && command!=at” | auditpr -v > auditstream.out &

This command would exclude from the audistream.out file the information that would be gathered from cron and at. This is probably not something you would want to do in your circumstance.

* See the AIX System Security Audit technote for more information on using auditselect.

3) Edit the /etc/security/audit/objects file to add an entry for the object/file you want to audit (replace path/to/filename and FILENAME with actual path and filename to be audited)

eg:

/path/to/filename:
w = “S_FILENAME_WRITE”

The above line will audit writes to the file, but you can also audit reads and/or execute (for commands) with…

r = “S_FILENAME_READ”
and/or
x = “S_FILENAME_EXECUTE”

4) Edit the /etc/security/audit/events file to include the following:

* /path/to/filename
S_FILENAME_WRITE = printf ” %s “

If you included READ and/or EXECUTE entries in step 3, you will also need to add the following entries to the events file…

S_FILENAME_READ = printf ” %s “
and/or
S_FILENAME_EXECUTE = printf ” %s “

5) Start auditing. On the command line type:

# audit start

if you need to reset auditing for any reason, simply exec…

# audit shutdown; audit start

6) Wait until the issue to occur, or perform steps to duplicate the problem being audited.

7) Stop auditing and check the output file for FILENAME entries

# audit shutdown
# cd /audit
# cat stream.out

The audit record is displayed as follows (example is for auditing a WRITE to a file)…

S_FILENAME_WRITE root OK Wed mar 06 2012 <application_name>
audit object write event detected /path/to/filename

 

Source:  http://www-304.ibm.com/support/docview.wss?uid=isg3T1013098

Comments Off

AIX System Security Audit

Comments Off

Question

AIX System Security Audit

Answer

 

This document is intended to simplify the use of the auditing system provided in AIX and applies to all versions of AIX. It includes information on what auditing offers, what its requirements are, and what common problems may be encountered. The intention is not to answer every question about auditing but to provide a starting point for understanding and setting up auditing.

Overview
Auditing events and objects
Auditing mode: BIN and STREAM
Starting and stopping audit
Auditing configuration
Auditing a user
Auditing an object
Disk space consideration
Understanding the output
Common problems with auditing
Data overload
Fixes for auditing subsystem
Related documentation


Overview

The auditing subsystem provides the means to record security-related information and to alert system administrators of potential and actual violations of the system security policy. The information collected by auditing includes: the name of the auditable event, the status (success or failure) of the event, and any additional event-specific information related to security auditing.


Auditing events and objects

A list of audit events built into AIX, along with a list of predefined audit objects, can be found in the file /etc/security/audit/events.

In general, auditing events are defined at the system call level. A single operation at the command line would result in records of several events in the audit trail. For example, when viewing a file using the cat or more command, you would see the following records logged into the audit trail:

FILE_Open (file is opened)
FILE_Read (file is read)
FILE_Write (file is written to standard output)
PROC_Create (process creation for more OR cat)
PROC_Execute (command execution)
PROC_Delete (process completion)

Auditing all possible events can produce a huge amount of data. Through audit controls (that is, modifying the configuration files), you can select events to be recorded.

Audit events are grouped into classes. The events can be defined by which events are in a class. While the class names are arbitrary, they, rather than individual event names, are associated with user IDs when the audit subsystem is active.

Auditing objects are just individual files that will be monitored. Three operations can be audited: read, write, and execute. Objects are not associated with user IDs. Audit records are generated whenever an audited object is referenced by any user (including root).

To add further audit objects, extend the /etc/security/audit/objects file.


Auditing mode: BIN and STREAM

There are two modes of operation for auditing: BIN and STREAM. BIN mode writes the audit trail to alternating temporary files (bins), then to a single trail file. STREAM mode writes to a circular buffer that is read synchronously through an audit pseudo-device (/dev/audit).

An audit can be started in one OR both of these modes.

Using the audit configuration setup shipped with AIX, /etc/security/audit/config, the BIN mode alternates between /audit/bin1 and /audit/bin2. When one BIN is full (the binsize parameter determines the size of the bin), the audit switches to the other BIN file while adding the accumulated data in the first file to the audit trail (defined in /etc/security/audit/bincmds), /audit/trail. Use audit shutdown to be certain that all audit records have been added to /audit/trail. The BIN mode audit record is in binary format. You can read it with audit commands such as auditpr.

In STREAM mode, the default AIX configuration provides a program to read the STREAM buffer and processes each record with the commands found in /etc/security/audit/streamcmds. These commands format the output into human-readable form and write it in /audit/stream.out. This file is NOT cumulative; it is restarted every time the audit is restarted. The STREAM audit trail can be read in real time by reading /audit/stream.out, or by sending output directly to a terminal or printer.


Starting and stopping audit

There are five audit subcommands for invoking auditing. They are as follows:

 

audit start
to activate the audit subsystem (This is the only correct way to start audit.)
audit shutdown
to stop auditing subsystem, processing final BIN records and removing the /audit/auditb file that is used as an “active” indicator by the audit modules
audit off
to suspend auditing temporarily
audit on
to resume audit after audit off
audit query
to display the status of auditing

NOTE: Using audit commands in the wrong order can confuse the auditing subsystem. If the auditing subsystem gets confused, reset everything by deleting all files in the /audit directory (except trail, stream.out and bin files).

Auditing can be run at the discretion of the system administrator. Depending on the environment, it is usually not necessary to have auditing running at all times. If it is configured to monitor a large number of events or objects at all times, the amount of data generated would be so substantial that its overhead would outweigh its benefit. It is worthwhile to take time to configure auditing to collect selected information.

To start auditing at system startup, add the following line to the /etc/rc file, just prior to the line reading dspmsg rc.cat 5 'Multi-user initialization completed':

    /usr/sbin/audit start

If auditing is running at all times, make sure to run or to add the ‘/usr/sbin/audit shutdown’ command to /etc/rc.shutdown which is called by /usr/sbin/shutdown (if it exists). Changes made directly to /usr/sbin/shutdown will be lost if/when the script is updated by OS/TL updates.

    /usr/sbin/audit shutdown    (should be added to /etc/rc.shutdown)

Auditing configuration

All auditing related configuration files reside in /etc/security/audit. The /etc/security/audit/config file contains the key audit controls. It has the following stanzas:

 

  • start specifies whether BIN or STREAM (or both) should be used for auditing
  • bin and stream contain controls for each mode; the names of the BIN files are specified here
  • classes defines several groups (classes) of auditing events

The predefined classes are: general, objects, SRC, kernel, files, SVIPC, mail, cron, and TCP/IP. New classes can be defined using the auditing events in the /etc/security/audit/events file. All audit classes except the objects class are associated with user IDs. For example, audit the events defined as general and TCP/IP for user root.

 

  • user stanza lists specified users and the audit classes assigned to them; each user name must be the login name of a system user or the string ‘default’.

An example of this stanza is as follows:

           users:
                       root = general
                        joe = general, files, TCPIP
                    default = general

When auditing starts, it ALWAYS audits the events specified for every user ID defined in the config file and ALL the objects defined in /etc/security/audit/objects. If the objects’ audit records are not wanted, remove or comment out (using an *) the objects defined in the objects file.

If there are specific classes of events that are not wanted as audit records, specify No_Events for that specific class in the config file.

For example:

    files = No_Events
          or
    tcpip = No_Events

The objects file contains all objects to be audited when auditing is active. A user defined object is displayed as:

    /home/joe/my.stuff:
                        r = "JOE_READ"
                        w = "JOE_WRITE"

The names JOE_READ and JOE_WRITE are referenced in the /etc/security/audit/events file to define the format of the auditpr output:

    JOE_READ = printf "%s"
    JOE_WRITE = printf "%s"

NOTE: There is no need to add the newly added objects to the objects stanza in the /etc/security/audit/config file, since the objects line is not referenced. Only the objects file is referenced.

The streamcmds file has commands that are entered for STREAM audit records. The default file contains one command.

Enter:

    /usr/sbin/auditstream | auditpr > /audit/stream.out &

Adding the -v flag for the auditpr command improves this command at the expense of having more information. Without -v, full path names for files are not shown in the audit output; only file descriptors are recorded.

To limit the amount of data collected during the auditing operation, use the -c option on the auditstream command to select a specific class of events as defined in the config file, or use the auditselect command to select specific events.

For example:

 

NOTE: This command must be all on one line in the streamcmds file. This command will collect only FILE_Open event records.

 /usr/sbin/auditstream | /usr/sbin/auditselect -e "event == FILE_Open"
 | auditpr -v > /audit/stream.out &

 

NOTE: The following command will limit data collection to only the TCP/IP class of events as defined in the config file.

    /usr/sbin/auditstream -c tcpip | auditpr -v > /audit/stream.out &

The bincmds file contains commands that are entered whenever a BIN file fills or when auditing is shut down. The file distributed reads like the following:

    /usr/sbin/auditcat -p -o $trail $bin

The environment variables in the preceding command are defined while auditing is active. The auditselect command can be added to select specific events, reducing the amount of audit records.

The bincmds file will only collect audit records that match USER_SU or USER_Login audit events. Enter:

    /usr/sbin/auditselect -e "event== USER_SU || event== \
      USER_Login" $bin > /audit/trail.login

Auditing a user

For example:

  1. To audit classes, use the fastpath command smit chuser.
    *User NAME              [joe]
    AUDIT classes           [general, files]

    A user stanza should be displayed for joe in /etc/security/audit/config file.

  2. At the command line, edit the /etc/security/audit/configfile. In the classes stanza, add the following new class:
        procmon = PROC_Create, PROC_Delete, PROC_Execute

    In the users stanza, the following could exist:

        joe = procmon

    The newly assigned audit classes will take effect at the next login for user joe.

  3. The BIN mode audit trail can be read with the following:
        auditpr -v < /audit/trail | more

The STREAM mode audit file /audit/stream.out can be viewed directly. Remember that the /audit/stream.out file is rewritten each time the auditing subsystem is started. Save the old stream.out before starting auditing.

If you do not want the objects audit records when auditing a user ID, comment out the objects defined in the /etc/security/audit/objects file or rename this file.


Auditing an object

In the following example, all processes writing to the /etc/utmp file will be audited.

  1. Edit the /etc/security/audit/objectsfile to add the following:
    /etc/utmp:
    w = "UTMP_WRITE"
  2. Edit the /etc/security/audit/eventsfile to include the following:
    * /etc/utmp
    UTMP_WRITE = printf " %s "

    The audit record is displayed as follows:

    UTMP_WRITE      root    OK      Wed Jul 12 12:12:25 1995  init

In this case, the init process owned by root wrote to the file.

NOTE: The length of an audit event or object name cannot exceed 15 characters. This limit is defined in the header file /usr/include/sys/audit.h, ah_event [16]. The following error message usually indicates an invalid event or object name.

     "auditevents (): Invalid argument"

Disk space consideration

Each record in the audit trail takes about 50 to 150 bytes depending on what mode is used and whether the verbose mode flag is specified. This means that 1MB of data could contain about 6800 entries.


Understanding the output

It is important to specify what information should be reviewed while auditing. Although you can configure auditing to record events of interest, there may still be too much data to be useful when viewed all at once. The auditselect command can be used with auditpr to sort through volumes of information and pull out only that which is needed for a specific report. It can be used to pull all data from a specific time period, for a specific user, or for a specific event, or any combination of these three.

For example:

    /usr/sbin/auditselect -f /audit/pick \
    /audit/trail | /usr/sbin/auditpr -v

The /audit/pick file reads as follows:

    command == rlogin && \
    time >= 08:00:00 && time <= 17:00:00 && \
    data >= 04/01/96 && date <= 04/12/96

This command reports the use of the rlogin command within the specific time interval (8AM-5PM between April 1 and April 12).

The compressed trail data from the binmode auditing is not in the same format at AIX version 3.2 as it is in 4.1 or later. There is a utility to convert the data from a pre-AIX Version 4 format to the Version 4 format. It is a command called auditconv.


Common problems with auditing

Errors when starting audit

  • There are certain errors that appear when running audit start.Error message:
        ** failed setting kernel audit objects

    This occurs when there is a syntax error in the /etc/security/audit/objects file.

  • Error message:
        auditbin: ** failed backend command
        /etc/auditcat -p -o /audit/trail -r /audit/bin1

    This error can be corrected by removing or renaming the BIN files. It is sometimes helpful to run audit shutdown again and then to retry audit start.

  • Error in configfile:It is necessary to have the user stanza in the /etc/security/audit/ configuration file or the following error will display when you start auditing:
        Unable to find the user stanza in /etc/security/audit/config

If it is not obvious that the user stanza is missing, verify that each of the classes are defined on a single continuous line.


Data overload

Given the way that cron and the TCPIP code is written, each sets up its own set of audit events. These events will get written into the audit trail regardless of how the config files are set up. The workaround is to use auditselect to exclude these events when generating the audit report. TCPIP sessions, ftpd, rexecd, and telnetd all call auditproc() to set up process auditing using the class tcpip in /etc/security/audit/config. The same thing is done in the cron code (at, cron, and cronadm) for the cron class in /etc/security/audit/config. These events will be written into the audit trail. The best thing to do is to filter them using auditselect.

For example:

    auditselect -e"event!=AT_JobAdd && event!=AT_JobRemove && 
..."

This will exclude events AT_JobAdd and At_JobRemove and so on.

Or select on the command name:

    auditselect -e"command!=cron && command!=at && ..."

This excludes recording related to commands, at, cron, and so on.


Fixes for auditing subsystem

 


Related documentation

Documentation for System Auditing can be found at the following:

AIX 6.1

Advanced Accounting subsystem:

http://publib.boulder.ibm.com/infocenter/aix/v6r1/topic/com.ibm.aix.accounting/doc/accounting/accounting_pdf.pdf

Chapter 3 of the System Management Guide: Operating System and Devices for AIX version 4
AIX 5L Documentation Library online at http://publib16.boulder.ibm.com/pseries/

Comments Off