Hardening AIX

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 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:      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. 2. 3. 4. ftp telnet other? 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 o The xss command uses the enhanced MIT screen saver extensions. o 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. o Alternatively, leave only hard disk in the boot device sequence, and set the privileged-access password. The system will boot only from hard disk. o 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. o 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, EFixes, 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 o Define standard groups, add to system install o 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 o tripwire, lsof, md5, logcheck, rdist, tcp wrappers o possibly: snort, tocsin o monitoring scripts o auditing scripts SysAdmin o 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