(rough outline draft #2
I started this in Nov.2001, but the project was abandoned..)
NOTE: This is an early working draft, and as such is
not very easy to read. I apologise for this, but the idea is to produce an outline, which
then can be improved up and refined.
By Seán Boran
This document presents a step-by-step approach to securely installing
AIX 4.3 (TBD exact version) for use in a sensitive environment. All steps have been
tested on Pilot Globe systems.
The focus here is on preparing the Operating System to securely run
services, rather than the setup of the services themselves. An accompanying tool will be
developed to allow corresponding automated hardening.
The process of hardening involves installing patches, disabling unneeded
services, configuring accounts correctly, restricting file permissions, limiting SID/SGID
files, configuring OS security features, and monitoring the system for unusual behaviour.
- Initial OS installation
- Minimize network services
- Minimise Inetd
- Minimize /etc/rc.tcpip
- Minimize /etc/rc.nfs
- Minimize inittab
- Minimize other services
- Kernel Tuning
- File / Directory Access Control
- System Authentication / Access Control
- User Accounts and Environment
- Hardening specific services (optional for later?, or refer to other documents?): snmp,
smtp, http, dns, time sync & ntp, AIXwindows/CDE.
- Install additional security tools
- Create Tripwire image, backup, test
- Maintenance: monitoring | Software patches
- Keep things simple: it is expected that only one or two services will run on a host. Use
several machines, rather than one superserver that does everything. It's easier to isolate
applications, harden and troubleshoot. Be minimalist, only run what is absolutely
- Hardware: Consider installation via the serial port console, get rid of the keyboard,
screen and framebuffer. i.e. avoid using X11 and get to know the command line. Have an
isolated, trusted network available for testing.
TBD: can AIX do this?
- Know exactly what the system is supposed to do, what it's hardware configuration will be
etc. hardening is generic and may break certain functions. e.g. AIXwindows/CDE may need
RPC to run but you really don't want RPC running on a sensitive host?
- It's important to understand how the applications work (how they use ports, devices,
files), to judge what hardening is possible and to assess the risk posed.
- boot via serial console
- installation example
- additional OS packages
- patch bundle
Network services present a significant risk to security:
- Only enable the strict minimum of services needed. The number system processes listed by
"ps ef" or equivalent should be less than 10.
- Use encrypted tools (like SSH) rather than clear-text network logins (e.g. telnet, 3270,
ftp, rlogin, rcmd).
- Keeping up to date with security patches on network daemons is particularly important.
- Daemons should run as non-root users.
- Daemons should "chroot" to a dedicated directory.
- Use encryption where possible to prevent snooping or replay attacks.
- Services must use minimal umask, file permissions etc.
- Strong authentication (with token or lists) should be considered for critical services.
- Applications should package structure
Minimise Inetd network Services
Inetd a process which automatically starts certain daemons such as telnet,
ftp, if connections are made.
Inetd services can be enabled or disabled with the command 'chsubserver'
on AIX. Likewise after changes to inetd configuration, the daemon needs to be send a
hang-up signal - 'refresh -s inetd'. For example:
[server1]# chsubserver -d -v daytime -p udp
[server1]# chsubserver -d -v daytime -p tcp
[server1]# grep daytime /etc/inetd.conf
#daytime stream tcp nowait root internal
#daytime dgram udp wait root internal
It is recommended that ALL services except the following be disabled:
..... TBD list ...
The can be achieved with the following commands:
chsubserver -d -v daytime -p udp
chsubserver -d -v daytime -p tcp
..... TBD list ...
Special services which may be needed (discuss what measures to take for
tftp - for diskless booting : /etc/tftpaccess.ctl
Minimize /etc/rc.tcpip network services
A description of what services are started in /etc/rc.tcpip and how they
can be changed with chrctcp.
/usr/sbin/no -o clean_partial_conns=1
/usr/sbin/no -o bcastping=0
/usr/sbin/no -o directed_broadcast=0
/usr/sbin/no -o ipignoreredirects=1
/usr/sbin/no -o ipsendredirects=0
/usr/sbin/no -o ipsrcroutesend=0
/usr/sbin/no -o ipsrcrouterecv=0
/usr/sbin/no -o ipsrcrouteforward=0
/usr/sbin/no -o ip6srcrouteforward=0
/usr/sbin/no -o icmpaddressmask=0
/usr/sbin/no -o nonlocsrcroute=0
/usr/sbin/no -o tcp_pmtu_discover=0
/usr/sbin/no -o udp_pmtu_discover=0
/usr/sbin/no -o ipforwarding=0
Minimize /etc/rc.nfs network services
A description of /etc/rc.nfs
secure nfs : /usr/secretdata -secure
Minimize inittab services
A description of what services are started in /etc/inittab and how they
can be changed with mkitab and rmitab.
Minimize other services
- Restrict AIXwindows/CDE login to console
- The xss command uses the enhanced MIT screen saver extensions.
- xauth, xhost
- Disable anonymous ftp
- Disable anonymous ftp writes
- Disable ftp to system accounts
- Lock down root access
The default configuration allows telnet and rlogin access to
the root account. This can be configured in the /etc/security/user file -- set the rlogin
option to "false" for all system accounts. System managers should login to their
account and then su so we have an audit trail.
- disable SNMP readWrite communities
The default SNMP configuration includes these "readWrite" communities:
grep readWrite /etc/snmpd.conf
# readOnly, writeOnly, readWrite. The default permission is readOnly.
community private 127.0.0.1 255.255.255.255 readWrite
community system 127.0.0.1 255.255.255.255 readWrite 1.17.2
- nis, nis+
- If possible, configure the system option to reduce "stack overflow" attacks,
limit core file size.
- Configure the OS for strong TCP sequencing, resistance to syn flooding and similar DOS
- TBD: broadcasts & multicasts
The default syslogd(8) configuration does nothing -- you won't get any important
messages logged unless you configure the file /etc/syslog.conf.
Only programs that are writing into audit logs should have write access to these log
Consider splitting logs by applications and priority. Consider centralised logging,
analysis of usage statistics and reporting of exceptions. Consider logging more that the
- log rotate, archiving
- Enable SU logging to console in /etc/default/su.
- Enable logging of failed attempts to login: touch /var/log/loginlog; chmod 600
/var/log/loginlog; chgrp sys /var/log/loginlog
5.1 Root directory
5.2 Application and System files and directories
5.3 System directories
5.4 Login Shell scripts
5.5 Home Directories
5.6 SUID and SGID programs
5.7 Dangerous files
5.8 Filesystem mounting
To reduce the risk of trojan horses and unauthorised modifications, in /etc/vfstab,
mount / with options "remount,nosuid", /var with "nosuid", /tmp with
"size=100m,nosuid" (allow /tmp to only use 100MB of swap space and disallow
execution of SUID programs).
Use the command virscan on filesystems that may contain files that are transferred to
ACL commands : aclget Gets the ACL for a file. aclput Sets the ACL for a file. acledit
Combines aclget and aclput.
Batch Utilities: at/cron
Users are not allowed to use 'cron' or 'at', access to these tools to be restricted
accordingly. System accounts should be explicitly given access if needed. Enable logging
of cron activity. Ensure that all command scripts that are to be executed with root
privilege by cron, at, or batch are owned by root and set to mode 755 or more restrictive.
Devices: disks, tty*
Consider setting restrictive permissions on raw disk devices used by databases.
Ports: In /etc/security/login.cfg,or via 'smit login_port' we could set:
* Port NAME /dev/ttyp0
Allowed LOGIN TIMES 
Login RETRY DELAY 
Number of FAILED LOGINS before port is locked 
INTERVAL for counting failed logins 
REENABLE DELAY for locked port 
Edit /etc/security/login.cfg or try:
chsec -f /etc/security/login.cfg -s default -a herald=" NOTICE TO USERS\r\n\r\nUse
of this machine waives all rights to your privacy,\r\n\r and is consent to be
monitored.\r\n\rUnauthorized use prohibited.\r\n\r\n\r\nlogin: "
Consoles & boot security
- Should we set the power-on password?
- The power-on password protection is effective against reset as well as power-on, and
means the system can't be booted from CD to bypass password controls.
- Alternatively, leave only hard disk in the boot device sequence, and set the
privileged-access password. The system will boot only from hard disk.
- If the machine is already in a physically secure room, this may create more trouble than
it's worth (convenience). It is recommended that at least 'Unattended start mode' be
- Cover lock key?
- Privileged-access password for firmware access. If you set both power-on and
privileged-access passwords, only privileged-access password is required to start SMS.
TCB is a good tool to detect penetrations and configuration changes. It is not
installed by default. You have the option to install TCB during the initial installation.
It cannot be added without reinstalling AIX.
TCB monitors over 600 files, plus the devices (/dev), by default. It stores these files
in an ASCII file, /etc/security/sysck.cfg. Make a backup of this file to a floppy disk and
write protect it immediately.
We should be able to use this as an alternative to tripwire?
The installp command automatically updates the TCB when you install PTFs /i.e.
patches). However, E-Fixes, naturally, do not update TCB. So if you apply an E-Fix to your
system, you will need to manually update TCB.
Store TCB read-only on floppy? with backup config.
- Ensure that encrypted passwords are only stored in /etc/security/passwd and not
- Define standard UID/GID ranges.
- Define standard groups, add to system install
- Define standard members of security (auditors) and system (sysadmins) groups?
User account policy
- TBD: edit /etc/environment /etc/profile /etc/security/environ /etc/security/.profile
/usr/lib/security/mkuser.sys set default user environment
MANPATH TMOUT=3600 TIMEOUT=3600 PS1 umask) in /etc/profile /etc/.login and /.profile
- We can set several security relevant account details, for example via 'smit mkuser' or
TBD: define standards/examples and test (especially with SSH) - ?I've started adding some
example settings in green..
1 User NAME 
3 ADMINISTRATIVE USER? false
4 Primary GROUP 
6 ADMINISTRATIVE GROUPS 
7 ROLES 
8 Another user can SU TO USER? true
9 SU GROUPS [ALL]
11 Initial PROGRAM 
13 EXPIRATION date (MMDDhhmmyy) 
14 Is this user ACCOUNT LOCKED? false
15 User can LOGIN? true
16 User can LOGIN REMOTELY? true
17 Allowed LOGIN TIMES  06:00-20:00?
18 Number of FAILED LOGINS before  user account is locked 5
19 Login AUTHENTICATION GRAMMAR [compat]
20 Valid TTYs [ALL] 
21 Days to WARN USER before password expires 
22 Password CHECK METHODS 
23 Password DICTIONARY FILES  /usr/share/dict/words (and add
others from John the ripper)
24 NUMBER OF PASSWORDS before reuse 
Password History size - histsize 8
25 WEEKS before password reuse 
Password reuse min - histexpire 26
26 Weeks between password EXPIRATION and LOCKOUT
Password maxexpired 4
27 Password MAX. AGE 12 or 24?
28 Password MIN. AGE 0
29 Password MIN. LENGTH 6
30 Password MIN. ALPHA characters 4
31 Password MIN. OTHER characters 1
32 Password MAX. REPEATED characters 3
33 Password MIN. DIFFERENT characters 3
34 Password REGISTRY
// following setting limit how much system resources can be used
// some high limits could be set
35 Soft FILE size
36 Soft CPU time
37 Soft DATA segment
38 Soft STACK size
39 Soft CORE file size  0
40 Hard FILE size 
41 Hard CPU time 
42 Hard DATA segment 
43 Hard STACK size 
44 Hard CORE file size  0
45 File creation UMASK  027
46 AUDIT classes 
47 TRUSTED PATH? nosak
48 PRIMARY authentication method [SYSTEM]
49 SECONDARY authentication method [NONE]
- Set user defaults for above:
- User restricted shell?
Temporary access to existing accounts
Application/daemon account policy
- Ensure that the password is blocked and shell is set to /dev/null for all system
accounts except 'root' and sysadmin users.
- A system default of umask 027 or tighter is required?
Administrator/Privileged access account policy
- Set PATH (no ".", system directories first) and other variables (e.g. TERM,
IFS, LIBRARY PATH, MANPATH) in /.profile and /.cshrc or /.login
- The tsh shell is a good security tool. It only allows you to run programs that are in
the TCB and have the TCB mode set. We should at least recommend it's usage?
- Only allow root to be access via su (not console or network login):
Another user can SU TO USER? true
User can LOGIN? false
User can LOGIN REMOTELY? false
TBD: I think we should allow root to login to the console?
- A system default of umask 027 or tighter is required?
- Extended attributes?
- For sensitive accounts: One common method of increasing login security is to require two
passwords to authenticate an account. This is called 2 key authentication.
- SAK: /etc/security/login.cfg to the default stanza: sak_enabled=true
- roles: an alternative method of assigning sysadmin privileges? Maybe an alternative to
sudo or the commercial equivalent?
ManageBasicUsers: chsec, chuser, lsuser, mkuser
ManageAllUsers: chfn, chsec, chuser, mkuser, rmuser, chrole, mkrole, lsrole, rmrole chsec,
lssec, pwdadm chgroup, chgrpmem, chsec, mkgroup, rmgroup, chsec, chuser, lsuser, mkuser
ManageAllPasswords chsec, lssec, pwdadm
ManageRoles chrole, mkrole, lsrole, rmrole
ManageBackupRestore backup, restore
The chuser command is used when adding/removing a role to an existing user.
See also /etc/security/user.roles and /etc/security/roles and smit:
smit chrole To change the attribute values
smit lsrole To display the attributes and their values
smit mkrole To creates an entry for each new role in the /etc/security/roles
smit rmrole To remove a role
At this stage standard tools/utilities are going to be installed, the most important
being SSH. These tools should already have been compiled and tested extensively on another
machine. They are typically transferred as tar files, by CD or FTP.
- AIX tools - C2
IP Security (IPSec) port
filtering permits AIX to filter incoming IP packets
based on combinations of source IP address (more generally, a network
and netmask), protocol (TCP or UDP), and port number.
(perhaps we don't need TCP wrappers, this filtering seems to be just as good, if not a
little complicated. It's like a local Ipchains/IPfilter)
IP Security (IPSec)encryption
DACinet permits arbitrary ports (above 1024) to be designated as
privileged so that they may only be bound to a socket created by the
super-user. Examples would include ports used by Web-based System
Manager and X11.
DACinet also provides a means of restricting the ability of users, based on
user identity, to establish connections to TCP ports. (No similar feature is
provided for UDP ports.) This feature extends the IPSec address-based notion of port
filtering to permit only trusted users to establish connections to certain services (such
as Web-based System Manager).
- Install SSH for login access. Configure the ssh daemon (/etc/sshd_config) so that access
is restricted to named hosts with known public keys (/etc/ssh_known_hosts) and rhosts
authentication is disabled. Use .shosts rather than .rhosts, if remote admin is needed. If
telnetd/ftpd was still enabled, disable it in /etc/inetd.conf, once you have tested SSH.
- tripwire, lsof, md5, logcheck, rdist, tcp wrappers
- possibly: snort, tocsin
- monitoring scripts
- auditing scripts
Test - Do SSH and the standard tools work? Check log entries, check console messages.
Does the system behave as expected?
- When all is working fine, freeze /usr and if possible /opt:
Mount /usr and /opt read-only (in /etc/vfstab with "ro" option). This reduces
the risk of trojan horses and unauthorised modifications.
Mount other partitions nosuid (SUID programs cannot assume other identities).
Run the mount command to check that filesystems options are effective.
- If CD-ROMS are not needed for production, disable the volume manager (one less daemon,
one less security worry). It can always be re-enabled if needed later:
mv /etc/rc2.d/S92volmgt /etc/rc2.d/.S92volmgt
- At this stage install tripwire (or some other filechecker that uses secure hashing
algorithms), initialise it's database and run regular checks to monitor for changes. If
possible keep the tripwire master database on another machine or write-once media. Even
better, copy tripwire & it's database and run it remotely at regular intervals using
SSH. This makes it difficult for an attacker to know that tripwire is being used to check
- Backup the system to two tapes, one offsite.
9.2.1 Intrusion monitoring tasks
22.214.171.124 File integrity: size, permissions, ownership
nice tcbck -n tree
126.96.36.199 Network ports visible
188.8.131.52 Network traffic intrusion
9.2.2 Log Statistics
9.2.3 Log Exception monitoring
9.2.4 Availability / reliability
Processes, ping hosts, snmp, rpc, remote check of specific services.
9.2.5 Example Schedules: Daily, Weekly, Monthly
- On system installation, the latest security / recommended patches for the Operating
System and applications be installed.
- As time goes by, new weaknesses and corresponding patches will be published and these
must be installed on the system within two months. Alternatively, a patch
strategy for the system must be defined and approved that consists of:
a) How is notification of new relevant patches realised?
b) How often are patches applied
c) Patch procedure, for example: test patches on a test System, plan downtime, prepare
rollback in case of failure, apply patches, monitor for problems, document results.
- How do you decide whether a weakness is worth patching?
a) If the weakness concerns a remotely exploitable weakness in an active network daemon,
exposed to a hostile environment like the Internet, install it fast.
b) If the weakness concerns a local exploit of a tool not normally used, not a daemon and
on a host where only root or administrator accounts exist, it may be enough to install the
patch together with a bundle at the scheduled intervals.
c) If the weakness concerns a local exploit of a tool on a host where non-administrative
users have accounts with shell access, urgent action is advised
d) If the systems runs highly specialised software like databases, clusters etc. be very
wary of installing Kernel, I/O and driver patches. It is advisable to test patches on a
separate system first.
 AIX 4.3 Network Hardening
Information Systems and Technology University of Waterloo
A PDF version has been created:
 AIX - RS/6000
Documentation Library (IBM)
- Frequently Asked Questions about AIX and the
IBM RS/6000 (Usenix posting). Also a pdf
version for printing.
- AIX 4.3 Elements of
Security Effective and Efficient Implementation (by) Kosuge, Arminguad, Chew, Horne
& Witteveen 18-Aug-2000. Also a pdf version for
- Additional AIX Security
Tools on IBM pSeries, IBM RS/6000, and SP/Cluster, (by) Farazdel, Genty, Kerouanton
& Khor 20-Dec-2000. Also a pdf version for
- Exploiting RS/6000 SP
Security: Keeping It Safe, (by) Farazdel, DeRobertis, Genty, Kreuger & Wilkop
21-Sep-2000. Also a pdf
version for printing.
Several check commands (grpck, usrck, pwdck, and
tcbck) and list
commands (lsuser and lsgroup) are available for use by root or anyone in the
The grpck, usrck, and pwdck commands require a flag to indicate whether the
system should try to fix erroneous attributes.
Flags are: -n Reports errors but does not fix them. e.g.
grpck -n ALL
lsgroup -f ALL >> /tmp/check
lsuser -f ALL >> /tmp/check