1.1: AIX Security Guidelines

• This file is intended for helping AIX customers create a more secure system.

• Please ensure that you read and understand the corporate instructions. The actual documents can be viewed by typing in corpdir at a VM command line.
  • Corporate Instruction Number 119a; Inter-Enterprise System Connections:

  • Corporate Instruction Number 104d; Information Asset Security:

  • Corporate Guideline Number 301 : Security Guidelines for Local Area Networks

  • Corporate Instruction 116B : Classification and Control of IBM Information

• Risk acceptances are in place for the NER machines and the LAN that they are attached to. A copy of these risk acceptances can be seen by accessing the NERAIX disk and reading the AIXRISK document.

• Responsibilities
  • AIX Support is responsible for AIX security on the machines that it owns and manages. It is responsible for writing Risk Acceptances for its machines. It is responsible for compliance with Corporate Instructions except when other parties are specifically defined as responsible for certain instructions.

  • AFS AIX customers are responsible for classifying their own information. Customers are also responsible for following IESC and restricted space guidelines.

  • AIX support will ask AFS customers what their initial information classification should be and will inform the manager of each new user about compliance with the corporate instructions.

  • AIX support plans to provide a secure "clone" that our customers can use. Customers who do not use the clone and give us ownership of root on their machines must manage their own compliance to corporate instructions.

  • Site Security is responsible for appraising operating unit management of status of IA's annually.

  • AIX Support will provide guidance to the site on which risk acceptances are needed.

• Passwords
  • Password security can be a problem on AIX. Please use the following guidelines that come from the Information Security Standard ITCS 200. AIX does not lock out a person after a certain number of password attempts. This makes it crucial that your password can not be easily guessed.

  • -Do not use your userid as part of the password. (not reversed, doubled, or otherwise modified)

  • -Do not use any person's name.

  • -Do not use words that can be found in the on-line dictionary, especially for a networked or multiuser system.

  • -Do not use passwords shorter than six characters.

  • The password must contain at least one numeric and one alphabetic character.

  • A numeric character can't be in the first or last position.

  • -Do not use three or more characters in the same order as the current password. (If current password = passwd1, new one can't be passwd2)

  • -Do not use three or more consecutive repeating characters.(like aaa)

  • -Do not use swear words or obscene words; these are easy to guess!

  • -Do not duplicate any of your last 12 passwords.

  • -Do use passwords containing letters and numbers.

  • -Two small words with a number in between makes a good password.

  • -Including punctuation makes a good password.

  • -Please change the initial password as soon as you receive your account.

• Physical Security
  • We recommend that people do not keep the keys in their RISC machines. The key is needed to bring up a maintenance "operating system" that does not need a password. If there is a need for the machine to reboot unattended, the key should be turned to "normal" before it is removed. If the machine should not reboot unattended, the key should be turned to "secure" before it is removed.

  • PS/2's should have a power on password set to help prevent the unauthorized use of a maintenance operating system.

  • Keyboards should be locked when a user leaves the physical area of the workstation while logged on. AIX support provides an "xnlock" and "mlock" locks that can be used for this purpose. See the AIXUSG file on the NERAIX disk for information on how to access the common code disks where these programs are located.

  • Easily detached hardware (such as a mouse) should be locked in a desk when no one will be around for an extended period of time.

• Vendor Access to AIX
  • Before enabling vendor access to AIX, consult with Site Security and the I&TSS Vendor Coordinator. General guidelines for vendor access to AIX follow:
    • Vendors having AFS accounts have system:anyuser access to any IBM AFS cell that their machine is connected to. (Currently 33 sites with more being added all the time.) Many of these sites have adopted a default of universal read. Vendors do not have to log on to remote systems to get access to any information in AFS. It is available on their own workstation. Since vendors will have access to much more information than they have a need to see, their contract must address this issue in a manner approved by site security.

    • Before allowing vendors on an unrestricted LAN, a risk assessment is required.

    • Vendors should not be in NIS (yellow pages) because that allows them access to any NIS client that has not taken specific steps to prevent access by them.

    • Vendors who need AFS user ids must be assigned user ids that start with V2 or V8 and their password will be given to an IBM manager who will determine if they should be allowed this account.

    • All accounts need to be tied to an IBM serial number and vendors are no exception. The IBM manager of the vendor or the vendor contract manager's id should be used.

    • After a vendor id has been assigned, send a note with the id to the I&TSS vendor security person.

    • Connections to off-site vendors require compliance to CI119A.

    • No modems should be installed in any system that have vendor access without appropriate risk assessments because it could create an IESC allowing access to IBM information from outside.

• Automatic Access
  • If you want to automatically log on to remote systems without bothering to type in passwords, there are some files that can help you. We recommend that no one use any of these files unless there is an overriding business need that can't be met any other way. Typing in passwords may be tedious, but it can help keep your information secure. No one should use these files without recognizing the security exposure that they can cause, especially if you allow access to someone who also allows access to someone else ..........

  • The /etc/hosts.equiv file will allow hosts that are named there to login without a password. This requires root access. It also allows anyone on these hosts to log into your machine. This is absolutely the worst way to allow access to your machine since you do not have control over which users are added to the machines that are listed there.

  • The .rhosts file is a list of the remote hosts that are allowed to log on without a password. Use of the .rhost file is not encouraged because you can not insure that only the people you have selected will get access. Anyone that is listed in their .rhosts files will also be able to gain access to your machine without your knowledge or consent. It is much safer to type in a password each time you access a new host.

  • The .netrc file is on the user's home machine and contains a list of machine names, login names, and passwords. This is also a poor security choice because no one should store readable passwords on-line. If this account also had a .rhosts file, any number of people would have access to this file. It is much safer to type in a password than to use a .netrc file. If a .netrc file needs to be used to give root the ability to do a backup, make absolutely sure that no .rhosts or /etc/hosts.equiv files exist. Also give some consideration to moving your information to AFS.

  • If you go against these recommendations and use one or more of these files, you can lessen the potential damage by not using these files with root or any other userids with special authority. You should also make some attempt to insure that other people are not allowed automatic access to the userid's that you have given access to your system.

• AFS
  • Use AFS when available. AFS provides authentication by user id and allows better access control than AIX. AFS eliminates the need for logging in to different systems or using NFS mounted file systems to do a particular job since all information is equally available to every client in the AFS cell.

  • If you are an AFS client, do not run jobs on unfamiliar hosts. Use only hosts that are known to be friendly.

  • The owner of a batch job is responsible for making sure that the job is run on a friendly machine and is responsible for removing any residual information created while the job was running.

  • If you have a RISC/6000 in AFS, type: /usr/prod/tools/bin/config_security to be offered a shell script that will help you set up your system in a secure manner.

  • Do not access unencrypted ICR data from another site unless end-to-end encryption is absolutely known.

  • Do not place a .netrc that contains machines and passwords in an AFS account that is world-readable ( i.e. system:anyuser has greater than list authority ). Default settings for AFS accounts are not world-readable.

• Information Classification
  • AFS
    • In AFS, ACLs are used to determine the classification of the information. To determine how your ACLs are set, go to the directory you want to check and type: fs la

    • One classification group, ibm.confidential, ibm.internal.use.only, or ibm.unclassified should exist with list authority. The classification group ibm.confidential should be used for information that is classified IBM Confidential. The classification group ibm.internal.use.only should be used for information that is classified IBM Internal Use Only. The classification group ibm.unclassified is used for information that has been determined to not need any of the IBM classification levels. These classification groups exist only to demonstrate the classification of the directory. There is no one assigned to these groups so having them does not give additional authority to anyone.

    • If you want to reclassify a certain directory, use the confidential, iuo, or unclassified commands. (/usr/prod/local/bin/confidential, etc)

    • Information higher than IBM Confidential should not be placed on AFS.

    • Directories that are classified IBM Confidential will have all of the following:
      • Group ibm.confidential will have list authority.

      • The most authority that system:anyuser or system:authuser can have is list authority. System:anyuser refers to anyone with a token or without one. System:authuser refers to anyone with a token.

    • Directories that are classified IBM Internal Use Only will have all of the following:
      • Group ibm.internal.use.only will have list authority.

      • The most authority that system:anyuser or system:authuser may have is read and list authority.

    • Directories that contain information that does not need to be classified will have the following:
      • Group ibm.unclassified will have list authority.

      • Your semi-private and public directories fall into this category. The sole purpose for this category is to show that the information in this category has been determined to not need classification.

    • (NOTE: We no longer use a group called nonIBM)

    • DO NOT place any IBM CONFIDENTIAL information in the semi-private or public directories. These areas can be scanned by anyone looking for this information.

    • Classification on a file-to-file basis can be done by inserting the classification INTERNALLY in file headers ( where applicable ) .

  • Classification under basic AIX
    • AIX which is not being run under AFS can use the "classify" shell script to classify information by directories.

    • The "classify" script can be found on the NFS mounted tools disks. (See "/service" in the installation section)

    • The concept behind the classify script is that the classification in the /HOME/.CLASSIFY file is for the named directory and all others under it.

    • Alternate classification strategies are acceptable for individual departments as long as they are documented and followed.

  • Classification of removable media
    • Classify all your removable media such as floppy disks, tapes, and CDs with the proper IBM classification.

• NFS
  • If you NFS export information from one AIX workstation to another in read/write mode, there is an exposure that someone could hijack your NFS mounts by pretending to be you. It is much more secure to put your information inside of AFS. AFS allows the people or groups that you have selected to have immediate access to your information as long as they have authenticated with a password at login time.

  • If you export filesystems or directories with NFS, use the -access flag to limit the hosts that can mount the directories. The only exception is when you export something that is meant to be used by anyone and everyone with access to the LAN.

• Anyone with a modem connected to their workstation could be creating a security exposure. Permission for modems MUST be obtained from the Site IESC Coordinator before plugging them in if they can be called from outside of IBM.

• Check /etc/inetd.conf and make sure that rpc.rexd is commented out. A # in the first column position causes the line to be commented out.

• If you use entries in the /etc/hosts.lpd file to allow yourself to print from VM or MVS to your local printer, you should make sure that you have disabled the bsh (batch shell) from your list of printer queues. It is not a security exposure to allow anyone on VM to print to your local printer but it is a security exposure to allow anyone on VM to be able to execute commands through the batch shell on your machine.

• Do not use TFTP unless you have a need to distribute code. (such as running X-stations from your workstation) Comment TFTP out in /etc/inetd.conf. TFTP allows someone to take files off your system without authentication. If you must run TFTP, we recommend using a RISC/6000 at level 3.1.7 or later and editing /etc/tftpaccess.ctl with a line like: allow:/usr/lpp/x_st_mgr/bin. This will allow people to access only the specified directories. If you also run AFS, you will have to delete the "#" in front of tftp in /etc/inetd.conf each time you reboot the machine.

• Review who is trying to access your system on a daily basis.
  • Unsuccessful login attempts:
    • For a RISC/6000: who -a /etc/security/failedlogin

    • For a PS/2: who /etc/.ilog

  • Successful logins:
    • For both: who /usr/adm/wtmp

• Do not create or import suid or sgid shell scripts that change user or group access to root or some other privileged userid. Note: A "C" program is not a shell script.

• If you want the current directory to be part of your path, make sure that it is the last directory searched to reduce the chance that an improper file will be executed.

• If you do not use AFS, root should have a default umask of 022 so that it can install products properly. It can be set in /.profile and /.cshrc. Other user ids should have a umask set depending on the classification of the information and the need for other group members to access the information. A safe setting for other userids is 077 and this can be set in /etc/profile and in $HOME/.cshrc