Hardening AIX

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

Table of contents

1. Preparation
2. Initial OS installation
3. Minimize network services
   • Principles
   • Minimise Inetd
   • Minimize /etc/rc.tcpip
   • Minimize /etc/rc.nfs
   • Minimize inittab
   • Minimize other services
4. Kernel Tuning
5. Logging
6. File / Directory Access Control
7. System Authentication / Access Control
8. User Accounts and Environment
   
9. Hardening specific services (optional for later?, or refer to other documents?): snmp, smtp, http, dns, time sync & ntp, AIXwindows/CDE.
   
10. Install additional security tools
11. Create Tripwire image, backup, test
12. Maintenance: monitoring | Software patches
    
13. References

1. Preparation

• 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 necessary.
• 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.

2. Initial OS installation

TBD:

• boot via serial console
• installation example
• additional OS packages
• partitioning
• patch bundle

Minimize network services

Principles

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

securetcpip ?

Special services which may be needed (discuss what measures to take for each one)

1. ftp

2. telnet

3. other?

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

/etc/exports

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:

  [server1]# 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

• routing
• nis, nis+
•  

Kernel Tuning

• 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 attacks.
• TBD: broadcasts & multicasts

Logging

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

Consider splitting logs by applications and priority. Consider centralised logging, analysis of usage statistics and reporting of exceptions. Consider logging more that the UNIX defaults.

• 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

TBD:

• errpt| more

File / Directory Access Control

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

/etc/filesystems

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

Virus scanning

Use the command virscan on filesystems that may contain files that are transferred to /from PCs.

ACLs

ACL commands : aclget Gets the ACL for a file. aclput Sets the ACL for a file. acledit Combines aclget and aclput.

System Authentication / Access Control

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 [0]
Number of FAILED LOGINS before port is locked [0] 
INTERVAL for counting failed logins [0]
REENABLE DELAY for locked port [0]

Login Banners

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 enabled.
• 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.

s2/TCB Auditing

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.

/etc/security/audit/config

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.

User Accounts and Environment

General policy

• Ensure that encrypted passwords are only stored in /etc/security/passwd and not /etc/passwd
• Define standard UID/GID ranges.
• Groups
  • 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 editing /etc/security/user
  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) [0]
  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 [0] user account is locked  5
  19 Login AUTHENTICATION GRAMMAR [compat]
  20 Valid TTYs [ALL] []
  21 Days to WARN USER before password expires [0]
  
  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 [0]
       Password History size - histsize 8
  25 WEEKS before password reuse [0]
       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
  loginretries 20
  
  // 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 [2097151] 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 [022] 027
  46 AUDIT classes []
  47 TRUSTED PATH? nosak
  
  48 PRIMARY authentication method [SYSTEM]
  49 SECONDARY authentication method [NONE]
  
• Set user defaults for above:
  • /usr/lib/security/mkuser.default
  • /etc/security/user
  • /etc/security/limits
  • /etc/security/login.cfg
  • /usr/lib/security/mkuser.sys
  
• User restricted shell?

Temporary accounts

TBD

• Ensure expiry date set

Temporary access to existing accounts

TBD

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):
  smit chuser
  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?

TBD:

• 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
  ManageBasicPasswords pwdadm
  ManageAllPasswords chsec, lssec, pwdadm
  ManageRoles chrole, mkrole, lsrole, rmrole
  ManageBackupRestore backup, restore
  ManageBackup backup
  ManageShutdown shutdown
  RunDiagnostics diag
  
  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
  

top

Install additional security tools

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.
• Security
  • tripwire, lsof, md5, logcheck, rdist, tcp wrappers
  • possibly: snort, tocsin
  • monitoring scripts
  • auditing scripts
• SysAdmin
  • perl, gzip, top,

Create Tripwire image, backup, test

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).
Reboot.
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 the system.
  
• Backup the system to two tapes, one offsite.

Maintenance

Monitoring Tasks

9.2.1 Intrusion monitoring tasks

9.2.1.1 File integrity: size, permissions, ownership

nice tcbck -n tree
or tripwire?

9.2.1.2 Network ports visible
9.2.1.3 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

Software Patches

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

References

[1]    AIX 4.3 Network Hardening

Information Systems and Technology University of Waterloo
http://ist.uwaterloo.ca/security/howto/2001-01-15/
http://ist.uwaterloo.ca/security/howto/2001-01-15/aix-network-harden.tar

A PDF version has been created:
http://boran.dyndns.org/aix

[2]     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 printing.
• 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 printing.
• Exploiting RS/6000 SP Security: Keeping It Safe, (by) Farazdel, DeRobertis, Genty, Kreuger & Wilkop 21-Sep-2000. Also a pdf version for printing.

Auditing notes:

Several “check” commands (grpck, usrck, pwdck, and tcbck) and “list”
commands (lsuser and lsgroup) are available for use by root or anyone in the
security group.
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