Professional Documents
Culture Documents
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
o Principles
o Minimise Inetd
o Minimize /etc/rc.tcpip
o Minimize /etc/rc.nfs
o Minimize inittab
o 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:
• 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
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:
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
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
A description of what services are started in /etc/inittab and how they can be changed with mkitab and
rmitab.
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.
• 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.
TBD:
• errpt| more
/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.
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.
Login Banners
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.
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.
• Ensure that encrypted passwords are only stored in /etc/security/passwd and not /etc/passwd
• Define standard UID/GID ranges.
• Groups
o Define standard groups, add to system install
o Define standard members of security (auditors) and system (sysadmins) groups?
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 []
Temporary accounts
TBD
TBD
• 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?
• 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
top
•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
o tripwire, lsof, md5, logcheck, rdist, tcp wrappers
o possibly: snort, tocsin
o monitoring scripts
o auditing scripts
• SysAdmin
o perl, gzip, top,
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
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
• 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