Preparing for PCI-DSSv3

Anyone who (indirectly) handles card-holder data must be compliant by the end of 2014, and have procedures in place that they can demonstrate to an external auditor or PCI assesor, or they risk large fines and penalties.

The main points are:

  1. You must install and maintain a firewall(s) that protect all cardholder data and prevent any direct inbound connections to your production network.
  2. All vendor-supplied/default passwords must be (regularly) changed and a procedure put in place to audity and control this activity.
  3. All cardholder data must be encrypted and protected at rest.
  4. All cardholder data must be transmitted in encrypted form particularly when it is uses public or shared networks.
  5. All systems must be protected against malware and viruses, and the protection software must be regularly updated
  6. All systems and applications must be hardened in order to limit access
  7. All access to cardholder data should be restricted to those that actually need it for their job and that information should be limited to enable them to carry-out that function
  8. Strict access-control and authentication must be in place in order to limit and record all (attempted) access to system components or applications
  9. All physical access to cardholder data must be restricted.
  10. All (attempted) accessto cardholder data or systems must be recorded.
  11. System and processes should be regularly tested to ensure continuous compliance.
  12. There must be an adequate security policy in place which covers both physical components and the people using them.

These rules affect you whether you have local hardware or rely on a third-party to provide resources in the cloud.

I have spent the past four years creating an AIX scanning solution which tests more than 1000 aspects of your AIX system build and configugration, and produces a detailed HTML report which can be used to quickly audit your systems and to identify ommisions, misconfigurations, and mistakes.

Our team can help you to quickly audit your AIX system(s) for PCI-DSSv3 using SystemScan AIX. Result is a comprehensive Risk and Remendiation report tailored  to your specific environment.

Please feel free to contact Ekron Dries for more information at  or 0031 88 2583346.




/proc filesystem

There is a lot of useful information about all the active processes in “/proc” filesystem, unfortunately you need canot just “cat” the files as “/proc” is not a normal filesystem and contains a snapshot of the current system status, and may well have changed before you get the chance to examine it.  e.g.

      PID    TTY  TIME CMD
8847424  pts/0  0:00 -ksh
9437218  pts/0  0:00 ps

find /proc/8847424

Just listing the “/proc” filesystem tree for a process does give you a good idea of what the system is doing and which resources it requires, however you need to use specialist tools such as:

Tool Description
procstack Get Process Stack Trace
procflags Show Pending and Held Signals for Process
procsig Display Signal Action and Handlers for Process
procfiles -n pid Report stat and fcntl Info for All Open Files in Each Process
procwdx Display the Current Working Directory of the Process
proctree Display the Process Tree

to get more information.

The “/proc” entries contain the following information:

Directory or filename Description
/proc/pid/as Address space used by this process.
/proc pid/cred Contains a description of the credentials associated with this process.
/proc/pid/ctl Process control file.
/proc/pid/cwd A link that provides access to the current working directory of this process. Any process can access the current working directory of the process through this ink, provided it has the necessary permissions.
If you run “strings” against this file it gives the same output as “ls”.
/proc/pid/fd Contains files for all open file descriptors for this process.
/proc/pid/map Address space map for this process.
/proc/pid/object Directory for objects.
/proc/pid/psinfo Process status information.
/proc/pid/sigact Signal actions for this process.
/proc/pid/status Process status.
/proc/pid/sysent System call information for process PID.
Thread specific files
/proc/pid/lwp/tid Directory for thread.
/proc/pid/lwp/tid/lwpctl Control file for thread.
/proc/pid/lwp/tid/lwpsinfo Process status info for thread.
/proc/pid/lwp/tid/lwpstatus Status of thread.



Creating your own LPPs

It is common practice to create packages in RPM format, however very few people also realise that you can also create your own native AIX-format LPP (Licenced Program Product) packages with very little effort.

Start by downloading and installing the “freeware.bull.mklpp.rte” package from

The software is installed in “/usr/local/lib/mklpp-1.2” and you will find a “README” file and example directory that will get you started. The software itself is very old, however it should work for any version of AIX.

Next create a dedicated filesystem or directory to hold your LPP build tree. e.g. “/lppbuild” and cd to the new location.

Create a new LPP name and version number e.g.

newlpp mylpp-1.1.2 gnu.mylpp
creating LPP structure for Usr-only LPP

This creates the following files and directories:


Manually create a text file e.g. “cat ./.info/freeware.gnu.mylpp.rte.copyright” and include any legal information that should be distributed with the package.

Next edit the three scripts in “.info” so they contain the correct list of pre and post-reqs, and any package dependencies.

Unpack your new package files immediately beneath this directory and update the “./lpp_name” to include a list that will be included in the package e.g.

4 R I mylpp.gnu.mylpp {
freeware.gnu.mylpp.rte 01.02.0004.0000 01 N U en_US Example LPP
/usr/local 9
/usr/local/bin 229
/usr/local/lib 3
/usr/local/lib/gzip-1.2.4 146
/usr/local/lib/gzip-1.2.4/sample 24
/usr/local/man 3
/usr/local/man/man1 55
/usr/local/info 71

Change to the package subdirectory and generate the LPP:

cd mylpp-1.1.2/
rm -f .info/
rm -f .info/freeware.gnu.mylpp.rte.size
rm -f .info/freeware.gnu.mylpp.rte.inventory
rm -f .info/backup_files
rm -f usr/lpp/freeware.gnu.mylpp/liblpp.a
rm -f usr/lpp/freeware.gnu.mylpp/inst_root/liblpp.a
rm -f .info/liblpp.a
rm -f /home/root/lppdir/out/gnu.mylpp- /home/root/lppdir/out/gnu.mylpp- /home/root/lppdir/zip/gnu.mylpp- /home/root/lppdir/bff/gnu.mylpp- /home/root/lppdir/bff/gnu.mylpp-
Making directory list


You will need to experiment with this before you get your package to behave exactly as expected and care must be taken to avoid overwriting any files that belong to another package.




AIX 7.1 Introduces NTP version 4

AIX 7.1 now includes support for NTP version 4 which is far more accurate than previous versions.

To check which version is active examine the symbolic link:

If you are using version 3 you should see:

ls -l /usr/sbin/xntpd
lrwxrwxrwx    1 root     system           20 Apr 11 11:49 /usr/sbin/xntpd -> /usr/sbin/ntp3/xntpd

If you are using version 4 you should see:

ls -l /usr/sbin/xntpd
lrwxrwxrwx    1 root     system           20 Apr 11 11:49 /usr/sbin/xntpd -> /usr/sbin/ntp4/xntpd

Eac version of NTP is meant to be backwards compatible however you should always do extensive testing before relying on this in production.




Firmware Assisted Dumps

POWER6® processor-based systems enable system dumps to be firmware assisted. When performing a firmware-assisted dump, system memory is frozen and the partition rebooted, which allows a new instance of the operating system to complete the dump.

Firmware-assisted dump is now the default dump type in AIX V7.1, when  the hardware platform supports it. The traditional dump remains the default dump type for AIX V6.1, even when the hardware platform supports firmware-assisted dumps.

To see which kind of dump you are using:

# sysdumpdev -l
primary              /dev/lg_dumplv
secondary            /dev/sysdumpnull
copy directory       /var/adm/ras
forced copy flag     TRUE
always allow dump    FALSE
dump compression     ON

type of dump         traditional

To enable firmware assisted dumps:

# sysdumpdev [ -t { traditional | fw-assisted } ] [ -f {disallow, allow, require }]

Full memory dump options available with the sysdumpdev -f command

Option Description

disallow                         Selective memory dump only. A full memory system dump is not allowed. This is the default.

allow | allow_full          The full memory system dump mode is allowed but is performed only when the operating system cannot properly handle the dump request.

require | require_full     The full memory system dump mode is allowed and is always performed

AIX Version 6.1 Technology Level 1 introduced support for an iSCSI device to be configured as a dump device for firmware-assisted system dump. The sysdumpdev command supports configuring an iSCSI logical volume as a dump device. In AIX V6.1, it was mandatory that this dump device be located on an iSCSI boot device.

AIX V7.1, firmware-assisted dump also supports dump devices located on arbitrary non-boot iSCSI disks. This allows diskless servers to dump to remote iSCSI disks using firmware-assisted dump. The iSCSI disks must be members of the root volume group.




Does your system use Solid State disks

Some newer AIX servers come with SSD (Solid State) disks in order to increase performance and energy efficiency. You need to be running at least AIX 6.1TL06 to support them.

SSD disks cannot be mixed with traditional disks and cannot share the same volume-group. The LVM commands such as mkvg have been updated to include SSD-only options e.g. mkvg -X SSD

To see if you are using SSD:

lsdev -Cc disk | grep SSD
hdisk9 Available 01-08-00 SAS RAID 0 SSD Array
hdisk10 Available 01-08-00 SAS RAID 0 SSD Array
hdisk11 Available 01-08-00 SAS RAID 0 SSD Array




AIX7.1 increased number of user groups

Previous versions of AIX allowed a maximum of 128 groups. AIX 7.1 has increased this to 2048
(NGROUPS_MAX). and added a new kernel (sys0) parameter ngroups_allowed.

To check the current limit:

lsattr -El sys0 -a ngroups_allowed 
ngroups_allowed 128 Number of Groups Allowed

To increase it to the limit:

chdev -l sys0 -a ngroups_allowed=2048
sys0 changed



Preventing your users from choosing obvious passwords

There are two kinds of obvious passwords:

1. Dictionary words or common acronyms
2. Names or phrases that are in common use within your organisation

Fortunately there are some simple ways to prevent users making poor choices:

1. Enforce password history. This prevents a password from being re-used.

chsec -f /etc/security/user -s default -a  <setting>=<restriction>

histsize = 4
histexpire = 26
minage = 1
maxage = 52
maxexpired = 8

2. Set password pattern restrictions e.g. a password must have at least one capital letter or number

chsec -f /etc/security/user -s default -a  <setting>=<restriction>

logintimes =
pwdwarntime = 5
loginretries = 5
minalpha = 2
minother = 2
minlen = 8
mindiff = 4
maxrepeats = 2

3. Use a custom dictionary to prevent the use of words that are in common use in your organisation or are so common as to be easily guessed:

Create a text fileor use the standard “/usr/share/dict/words” file and create a list of banned words or terms e.g.


Set the AIX default password restrictions to check these words when a user changes their password:

chsec -f /etc/security/user -s default -a dictionlist=/usr/share/dict/words

Once the restrictions are in place the users are then prevented from choosing a word from this list:

Changing password for “test”
test’s Old password:
test’s New password: (the password entered is “test”)
3004-335 Passwords must not match words in the dictionary.



Running a server in Turbocore Mode

You can configure a model 780 or 795 server to run in TurboCore mode (rather than the standard MaxCore mode) in order to improve performance of processes that cannot take advantage of threading. In this mode up to half of the processor cores on each single-chip module (SCM) are disabled and their L3 cache is made available to the active processor cores on the chip, which provides a performance boost to the active cores.

The number of cores used in TurboCore mode is equal to the number of activated processors, but only up to a maximum of half the number of cores physically installed.

A server with 32 physical processor cores (14 activated), running in TurboCore mode. If you re-IPL the system and switch to MaxCore mode, you now have 14 processor cores running in MaxCore mode. The same is true if you switch from TurboCore to MaxCore mode.

If the server has an odd number of activated cores only half the number of physical cores will be available.

There are special rules that apply when ordering a 780 or 795 that is intended to be used in TurboCore mode. The server can be delivered ready configured in this mode.

The change applies to the entire server and not just an LPAR and is managed via the ASMI interface.



Managing you cron logs

Previous versions of AIX would keep writing to the same cronlog until either the disk filled, you restarted the process, or manually managed the file. AIX 6.1 introduced the “/etc/cronlog.conf” configuration file and it is now possible to automatically limit the size of the log file an to automatically rotate versions e.g.


Will write to “cron.log” and automatically rotate and compress it:

# ls -l /var/adm/cron.log*
-rw-rw-r–    1 root     cron          79986 Aug 25 14:00 /var/adm/cron.log
-rw-rw-r–    1 root     cron          15301 Aug 12 13:40 /var/adm/cron.log.0.Z
-rw-rw-r–    1 root     cron          15018 Aug 16 11:45 /var/adm/cron.log.1.Z
-rw-rw-r–    1 root     cron          14334 Aug 18 13:45 /var/adm/cron.log.2.Z
-rw-rw-r–    1 root     cron          14878 Aug 21 06:40 /var/adm/cron.log.3.Z