Minimum Security Base

1.1.1

The root user's PATH variable does not include the Current Working Directory or its parent.

If the root user's PATH includes '.' or “..”, the user is vulnerable to trojan horse attacks residing in the user's current working directory or its parent.

The default path for the root user does not include any directories which are writable by other users.

1.1.2

Any user's PATH variable does not include the Current Working Directory unless it’s the last entry in the PATH; any specific $HOME directories must be after the standard system directories and before the current directories in a user’s PATH variable.

If a user's PATH includes '.' or “..”, the user is vulnerable to trojan horse attacks residing in the user's current working directory or its parent.

The default path for any user should not include any directories which are writable by themselves or other users until checking for system supported commands first.

1.2.1

Insecure Sendmail configuration options such as WIZ, VRFY, EXPN and DEBUG are not used.

Several of the Sendmail commands present serious security risks. For instance, the WIZ command allows anyone who knows the "Wizard" password to log into the system, gaining command line access. VRFY and EXPN ("verify" and "expand" respectively) allow anyone to query the Sendmail server as to the names of valid accounts on the system. DEBUG allows an outsider to put Sendmail in "debug" mode and execute commands on the system.

A mail program such as smap should be used.  Smap eliminates most of the security weaknesses associated with sendmail.

1.2.2

The Sendmail daemon is only  used if an approved business justification exists.

The Sendmail program is the mail system's routing program. The UNIX program /usr/lib/sendmail implements both the client and the server side of the mail program. Sendmail has been the source of numerous security breaches on UNIX systems. Security vulnerabilities have been found in all versions of Sendmail, up to and including Sendmail version 8.11.2  This is the latest version of Sendmail – see www.sendmail.com

On AIX, sendmail is started by the Run Control (rc) scripts.  Locate the entry for sendmail and comment it out.

In order for the changes to take effect, one must either reboot or kill the currently running sendmail process.

1.2.3

The sendmail.cf file allows only a minimal list of  "trusted users."

The /etc/sendmail.cf file contains configuration information necessary for sendmail to run, include options which can create security vulnerabilities in the mail system. The T configuration command identifies the "trusted users" who can override a sender's name in a mail message by using the -f option with one of their own. Trusted users are necessary for certain kinds of mail to flow properly, but other trust relationships can be added which introduce security vulnerabilities.

Remove any T sendmail.cf directives not listing uucp, root or daemon.

1.2.4

DNS is configured to disallow unauthorized zone transfers.

Zone transfers can be used by intruders to rapidly obtain a complete map of an organization's servers.  Such information is commonly used by intruders to facilitate target scanning and selection during break-in attempts.

DNS is configured to prevent unauthorized zone transfers as well as log unauthorized zone transfer attempts.

1.2.5

If the WAN architecture allows access from insecure networks such as the Internet, the server's network services are either disabled or implemented in a manner which appropriately minimizes the risk of intrusion from the insecure networks.

Many network services are unnecessary and may pose a security risk if enabled on servers accessable via the Internet or high risk WAN segments.

Only network services which are necessary for business operations are active.

1.2.6

The latest available version of BIND is installed on the system

Earlier versions of UNIX BIND contained security problems which might allow an attacker to gain access to the system

The latest available version of BIND should be installed.  Currently (01/17/2001/19/2000), the latest version is BIND 9.1.  You can find this information at www.isc.org.

1.2.7

The Sendmail Aliases file is configured securely.

An incorrectly configured /etc/aliases file may allow unauthorized access to the system.

1) The aliases file must be owned by root and protected mode 644.  Use the following command to check the file permissions:

ls -l /etc/aliases

They should read:

   "-rw-r--r--"

If permissions are incorrect, change them using the following command:

chmod 644 /etc/aliases

2) Review the entries in the aliases file, using vi /etc/aliases, and comment out any undesirable entries (using a text editor, place a comment "#" marker at the front of the line in question). In particular:

a) Remove the decode alias, which might appear in the alias file as follows:

    decode:  |/usr/bin/guudecode

b) Review for any other entries which execute a program. Remove if not necessary.

If NIS is used, run /usr/sbin/newaliases after changing the aliases file in order to rebuild the maps.

1.2.8

The Sendmail mail queue file is configured securely, with the minimum permissions necessary for operation.

Access to the mail queue can allow users to read other users mail, gaining sensitive information or to overwrite mail messages.

 Check the mail queue's permissions, by:

ls -l /var/spool/mqueue/mqueue

Since only the owner, root, should have access, the permissions should look like:

-rwx--

If permissions are not correct, change them by:

chmod 700 /usr/spool/mqueue/mqueue

1.2.9

The sendmail.cf file has secure file permissions.

If the Sendmail configuration file has improper file permissions (e.g., world writeable) there is an increased risk than an unauthorized user may gain privileged access to the system or cause a disruption of service.

The sendmail.cf file should be secured with appropriate file permissions.  The /etc/sendmail.cf file must be writable only by root with permission mode 640 or 660.

1.2.10

Sendmail is implemented in a secure manner, including immediate installation of the latest security patches as they become available.

Sendmail (a mail routing daemon) has been the source of numerous security breaches on UNIX systems.  Security vulnerabilities have been found in all versions of Sendmail, up to and including Sendmail version 8.8.11.2 (Sendmail is currently on version 8.11.2 as of 12/29/2000 .  You can find this information at www.sendmail.com.

Check www.ers.ibm.com for the latest patches; follow site instructions to install patch. Subscribe to the IBM ERS service to keep abreast of latest patches to install, as well as the CERT (www.cert.org) and Bugtraq (www.netspace.org) mailing lists for breaking news regarding Sendmail (and other) security vulnerabilities.  In addition, the latest information on sendmail can be found at www.sendmail.org.

Evaluate the need to run sendmail, and disable if the service is not used.  If sendmail is necessary, conisder using a more secure version (e.g, Qmail) or a sendmail wrapper (smrsh, SMAP / SMAPD).

1.2.11

Unnecessary RPC services are disabled.

RPC services provide unauthenticated or weakly authenticated access to systems to remotely execute commands (Remote Procedure Calls) for distributed computing. RPC is used for services such as NFS, but can be a significant vulnerability source.

Where RPC is necessary, secure versions of RPC which implement strong authentication and encryption are used.

1.2.12

Protect against an account name/password guessing attack

Parameters in the /etc/security/login.cfg file can be set by port to delay or prohibit additional logins after a failed login.

Consider setting the parameters appropriately to protect against a guessing attack on sensitive ports (i.e. a modem port).

Examine failed logins using

/usr/bin/who `-s` `/etc/security/failedlogin`

1.2.13

The organizational structure of the IS and security groups provides for adequate UNIX security.

I think you wanted to say IS personnel resources are insufficient to allow for the time and effort needed to address security issues, security needs are generally assigned a very low priority.

Sufficient lets either use IS or MIS not both  when talking about the same function.MIS resources should be devoted to security.  Job descriptions of system, network and database administrators should include security related tasks.

1.3.1

(If NIS is used) a current (i.e., patched) version of NIS is implemented for enterprise wide user authentication.

NIS offer a robust set of administration options that organizations can use centrally manage access to system resources.  However, there are many options that need to be configured correctly to provide security over the NIS environment.  Moreover, many security related vulnerabilities have been associated with NIS.  Thus, if NIS is not properly configured and patched, there is an increased risk an unauthorized user could gain privileged access to system resources.

Contact your vendor for the most up-to-date patches for NIS/NIS+.

To check for active NIS, use:

isypset=`domainname | /bin/grep “^[a-zA-Z]”

If active, to check the NIS domainname, use:

/usr/bin/domainname

1.3.2

If NIS is used, it only provides users with access to those systems they have a business need to access.

Users with domain-wide access may have privileges which go beyond their job responsibilities, including unauthorized access to sensitive files.

Limited access via NIS can be accomplished by creating one or more designated login shells on each machine. 

For instance, the server sales may contain the login shells /usr/local/salessh and /usr/local/salesapp, the former being a copy of /bin/sh and the latter being a shell which launches an application on this server. 

Most users will now have the NIS entry /usr/local/salesapp, while users requiring shell access to the server will have the NIS entry /usr/local/salessh.  These users can now be administered on a domain-wide basis, but their login access is limited to the server sales.

Note also that the .login/.cshrc/.profile files can play a role in controlling NIS access.

1.3.3

NIS configuration files have secure file permissions.

World-writable NIS configuration files could make it possible for an attacker to change NIS information, including adding privileged accounts.

NIS configuration files have restrictive permissions.  In particular, the passwd.adjunct file is not accessible by users other than root.

The umask value for the root user is set to 077 to ensure that files are created with secure default permissions.

1.3.4

NIS Master servers do not use NIS for password information.

Since NIS master servers are key to NIS security, and thus a point of compromise for the entire network, such systems should have extra security protections

NIS master servers use only local account information for authentication.

1.3.5

Root level UIDs are only defined on the local server and do not provide domain-wide access through the NIS password file.

If root IDs are implemented domain-wide using NIS, it is likely that system administrators will have privileged access to systems not required for their job functions, while the compromise of a single root account would result in the compromise of all systems in the domain.

NIS contains no root level UIDs (uid=0).

1.4.1

Access to the at command is limited.

The at command allow users to run commands at a later time, using the cron command queue.  The unrestricted use of these commands is a security risk.

Review the at.allow and at.deny files for appropriate entries, using the cat command. If users other than root have a business need to use the at and batch commands, create the at.allow and at.deny files to control which users can use the at command. The login names of users that are allowed to use the at command must be listed in the at.allow file. The at.deny file specifies the list of denied users.

These files must be owned by root and members of the sys group, with permissions mode 640.

Where necessary, add entries to at.allow and at.deny using a  text editor, and change permissions on these files using chmod.

1.4.2

Devices (except terminals) are not world readable, writeable or executable.

Improperly protected devices (which are represented to the UNIX OS as files) can leave systems vulnerable to attackers. For instance, if an attacker can write to the /dev/kmem device (kernel memory) with a debugger, he may be able to modify his UserID (to become root), modify data in system buffers, or write garbage over critical data structures, causing the system to crash. Similarly, unauthorized access to disk devices, tape devices, network devices and terminals being used by others can lead to problems.

Use the chmod command to set appropriate permissions on device files.

1.4.3

The network interface card should not be in promiscuous mode.

Most Ethernet cards can be placed in "promiscuous" mode, which enables a user to gather and review all Ethernet packets on the local subnetwork, including the data in those packets, such as passwords. Intruders will often attempt to install such gathering software (such as etherfind or tcpdump) upon breaking into the system, in order to gain further access.

To determine whether the network interface is in promiscuous mode, use the CPM tools, available from www.cert.org

1.4.4

Use of the  mount command should not be executable by users and any untrusted file system (i.e. CD-ROMS) should only be mounted without the ability to execute suid programs.

Users can inadvertantly mount systems over one another and do not need to routinely mount file susyems. A file system mounted, such as a CD-ROM may contain suid to root programs, allowing an attacker to gain root access.

Remove the mount command from world access and require untrusted file systems to be mounted with the –o nosuid option.

1.5.1

Corporate IS security policies include specific sections pertaining to the UNIX environment, including configuration guidelines to significant security areas.

AIX System Administrator that does not know and understand the Corporate IS security policies may wrongly configure the AIX system and thereby expose the system to security risks.

Review the corporate information security policies and procedures to determine if sufficient support exists for a controlled environment. UNIX policies should include specific configuration guidelines, tailored to particular environments such as "file servers," "DMZ systems," etc.

1.5.2

Procedures must be implemented for the regular acquisition and installation of vendor (both IBM and third party applications) patches and upgrades necessary to correct security flaws, as well as installation of workarounds for unpatched problems.

The system may be needlessly vulnerable to security flaws discovered on an ongoing basis, in terms of both system penetration and denial of service. System crackers are aware of security flaws, and will exploit them if patches are not implemented.

Inquire about the system administrator's procedures for obtaining the latest and Inquire about the system administrator's procedures for obtaining the latest and installing the security patches and workarounds.

Review vendor resources (including www.ers.ibm.com) and  security sites such as CERT (www.cert.org) and Bugtraq (www.netspace.org) for the existence of security-related system patches for the particular OS, and install said patches. If using an older version of the OS, upgrading to the latest version of the OS (plus any patches for that version is usually preferable to keeping the older version with patches. The IBM ERS web site contains  (but not for any other software such as a third party Web server or for Sendmail - consult other vendors as appropriate.

Important: Some patches may change to your system configuration to insecure defaults.installing the security patches and workarounds.

Review vendor resources (including www.ers.ibm.com) and  security sites such as CERT (www.cert.org) and Bugtraq (www.netspace.org) for the existence of security-related system patches for the particular OS, and install said patches

Important: Some patches may change to your system configuration to insecure defaults.

1.5.3

If significant programming is done on the server, an appropriate system development life cycle and change control methodology is in place.

A disorderly development environment, including problems such as a blurring of the development and production environments, insufficient quality assurance testing, insufficient documentation, and excessive programmer privileges, can lead to a breakdown in the security of the system and the integrity of the production data.

·        Develop applications on a development system. (NOTE: Development system needs to be completely separate from Production system and network).

·        Test new application/program on the Development/Test system. Provide the test criteria and application/program documentation.

·        Submit program to Quality & Assurance group for testing.

·        Develop a migration plan to the Production system.

·        Prepare a back-out plan.

·        Notify the system administrator about the migration and the tentative date.

·        If all tests have been conducted and passed, submit a change request following the Change Management Process.

·        If all authorizations have been obtained and the date approved, migrate to production according to plan.

·        Verify that the migrated application is working.

·        Provide any required maintenance documentation to the system administrator.

1.6.1

The server's physical surroundings are designed for the safety and availability of the system, including  cleanliness (lack of dust), appropriate and stable temperature and humidity, and neat and controlled cabling.

If a computer is not stored in a clean, cool environment, it may be subject to more breakdowns and loss of data.

Rooms containing critical servers should be climate-controlled.

If conditions are inappropriate, take steps to correct.

2.1.1

Each user has a unique user name and user ID.

UNIX tracks users by UID, rather than by username. Therefore, where users share UIDs, they may gain access to each others' files, while security administrators  will not be able to track specific security events to specific users.

All server user names and UIDs are unique.

The process for user addition and deletion is constructed so as to minimize the risk of duplicate user names and UIDs.

2.1.2

User account group identification (GID) codes should be greater than 100 and never be 1 or 0.  User account UIDs should be greater than 100 and must never be 0.

UNIX UIDs under 100 are reserved for system accounts.  By allowing users to have UIDs under 100, the risk is increased that the user will have access to information or resources that are reserved for more powerful system level accounts.

To change a user's UID or GID, use the smit tool.  Next, use the chmod command to change ownership any files owned by the old UID to the new UID.

2.1.3

User names follow an organizational naming convention.

Following a pre-defined set of standards allows for the easier recognition of new accounts that may have been created  in violation of policy, either by intruders or system administrators.

Best Practices call for a naming standard which makes it hard for outsiders to guess individual account names based on personal information. 

We have a namiming standard in the Account Management and MSB Introduction documents.  You may want to reference these two documents here. 

This naming standard prevents outsiders'  deriving user account names from publically available information such as employee names.  User account names can be used in combination with password guessing and social engineering to gain unauthorized access to systems.

2.1.4

Generic or group user accounts are not used.  A generic account is identified as a user account in which multiple users, on a regular basis, access and have knowledge of a single user  account with a known identification/password combination.

Generic user accounts limit accountability on user actions performed while logged in as a generic user. Use of a generic account are extremely difficult to audit since it is impossible differentiate between the activities of individual users, making it a high priority target for intruders.

If a generic account is identified, perform the following:

1.  Identify the purpose of the account,

2.  Identify all users of the account,

3.  Create unique accounts for all users of the generic account,

4.  Assign appropriate rights to all new user accounts, and

5.  Delete the generic account.

2.1.5

Third party tech support accounts are disabled, and only enabled temporarily as needed.

Vendor accounts are often left enabled, with default passwords shared among vendor employees and known to vendor ex-employees.

Vendor support accounts should only be enabled on a temporary basis.

Support contracts with third-party vendors should be reviewed to determine liability in case a break-in takes place through the vendor's network.

The third-party vendor should be contacted to determine whether secure systems practices are being followed, whether third-party security reviews have been performed, and whether such reviews are available for inspection.

2.2.1

Default system accounts that do not need to be used are disabled.

Default system accounts, such as daemon, bin, sys and adm,  are automatically created when the AIX Operating System is installed. Many of these accounts are never logged into but are instead place holders for software ownership.

The following accounts provided by default with AIX 4.x should be disabled:

daemon, bin, sys, adm, uucp, guest, nobody, lpd.

2.2.1

All user accounts should be managed consistently to minimize inappropriate account configurations.

Managing user accounts and their associated parameters by editing the native unix files, or even the mkuser command can lead to misconfiguartions creating a security exposure.

Use the smit utility whenever its capabilitiy is sufficient. All normal administration of user accounts should utilize the smit utility.

3.1.1

Accounts that run a single command, without authentication, are not allowed.

UNIX allows accounts that simply run a single command or application program (rather than a shell) at login. These accounts typically have no password and are used, for example, to allow people to log in as who to obtain a list of who is on the system, to log in as lpq to check the printer queue, and so on. Examples of such accounts include who, finger, lpq, mail, news, date, uptime, sync, and help. These types of accounts are often exploited by an intruder.

Delete any unauthenticated single command logins using the smit tool.

3.1.2

Dormant accounts are removed or disabled.

Dormant entries are a target for intruders, as the account user will not notice the activity.

Procedures should be in place for checking for dormant accounts on a regular basis.  Same comment as 2.4.1.

3.2.1

Passwords are not easily guessable, i.e. words found in a dictionary, or a variation on the user name; they do not pertain directly to a user's family or personal interests. While passwords should contain both alpha and numeric characters, passwords with special characters are even harder to guess or crack with a utility.

Passwords which are easy to guess give intruders an easy opportunity to break into the system.

Define password/user characteristics in /etc/security/user, /etc/security/mkuser.default, /etc/security/login.cfg

Minimum requirements (defined in /etc/security/user):

·        minlen=8

·        maxage=12

·        minage=1

·        maxrepeat=2

·        minalpha=5

·        minother=3

·        mindiff=3

·        maxrepeats=2

·        maxexpired=0

·        histsize=24

·        pwdwarntime=14

·        Set dictionlist= dictionary file of invalid passwords

Set minimum default values for smit user field (defined in /etc/security/user) for the default stanza as follows:

·        admin=false

·        login=true

·        su=false

·        daemon=true

·        rlogin=false

·        sugroups=ALL

·        ttys=ALL

·        auth1=SYSTEM

·        auth2=NONE

·        tpath=noask

·        umask=027

·        expire=0

3.2.2

A unique initial password must be assigned to all new accounts and all users must change their passwords immediately when using a new account for the first time and passwords are distributed in a secure manner.

If passwords are distributed in printed format or by e-mail, the likelihood is greatly increased that the information will fall into the hands of intruders, who can  intercept  e-mail or regularly check the office printer for password lists.

Initial system passwords should be created in a secure manner, for instance by using a random character generator.  Users should be required to obtain their initial system password in person and instructed to destroy any written material which may contain their password.  We have a clearly defined process for new user password creation and communication in our Account Management Policy and MSB Introduction.  We need to either reference these two documents or write the appropriate guidelines.

3.2.3

Root passwords should be different for each machine.

Using the same root password on all machines can lead to compromise of all machines with the compromise of just one.

The root password is set differently on each machine. The frequency with which they are changed should be irregular and unpredictable.

3.2.4

The root account does not allow for the separation of  duties.

Separation of duties is basic to security controls. The root account is all-powerful; access to this account for a subset of privileges violates this concept.

Utilize the Administrative Roles feature to achieve greater separation of duties and to reduce the number of personnel requiring the root account access.

3.2.5

The shadow password file is used, with appropriate file permissions.

The standard UNIX password file is world readable, so that anyone logged into the system can read the file and attempt to crack the account passwords, including root. The shadow password file removes this threat by moving the password information to a separate file, readable only by root. If the shadow password file is accessible by other users, the value of the shadow file is lost.

Password shadowing should be in use for every account on the system. No encrypted passwords should exist in the etc/passwd file (null, * and ! only in the password field).

3.2.6

Insure proper password maintenance.

Improperly maintained passwords can result in explotitation of the system and reduce user accountability.

To scan for password inconsistencies, use:

/usr/bin/pwdck –n ALL

To scan for group inconsistencies, use:

/usr/bin/grpck –n ALL

·        Both of these will report errors but will not fix them automatically.  To have the errors fixed, change the “-n” to “-y” in both cases.

Review /etc/passwd, /etc/security/passwd, /etc/security/group regularly for changes

3.3.1

Only one root level account (UID = 0) is defined on the server.

Multiple root level accounts increase the risk that users have system access privileges not required for their job functions.  In addition, intruders who target privileged accounts have multiple opportunities to gain root access.  It also becomes more difficult to maintain an accurate audit trail when more than one root-level user exists on the system.

Only one account with UID=0 exists on the system.

Administrators are required to log into their own unprivileged accounts and su to root.  No direct logins to the system as root are allowed.

Administrators are to never su to root from a user’s session without resetting the path variable or entering the full path for each command.

4.1.1

Employee accounts are removed in a timely manner after separation from employment.

Unnecessary accounts or accounts with unnecessary privileges create additional access paths for intruders.

Business processes should be in place which ensure that all organizational accounts are created, updated and deleted in a timely manner.

Often, and particularly in large orgainzations, software to support the above processes must be acquired.

4.1.2

End users are not provided command line (shell) access to the UNIX operating system unless necessary for their job functions.

Access to the command line via a shell (the command line interpreter) increases the risk that the user can access unauthorized resources, as well as the risk to the system if an account is compromised.

The following methods, in order of effectiveness, represent best practices:

1) Replace the shell located in the last field of the password file (cat /etc/passwd). with a menu program,

2) Use the chroot command to prevent user from accessing unauthorized files,

3) Give users a restricted shell with no access to cd, rm, cat, and other sensitive commands (historical implementations of restricted shells have often been found to be ineffective).

Note that restricting the shell is ineffective unless the rshd daemon is disabled on the server.

4.1.3

User configurable environment files should only be changeable by the user or root.

Only the user should have write access to these files and no other users need to be able to see them.

Group and world require no access privilieges to the following files:

$HOME./.profile

$HOME./cshrc.

$HOME./.Xdefaults

4.1.4

The umask is set to control access to newly created files.  Only the owner of a file has default permissions to read, write and execute the newly created  file.

Files and directories are created with a default set of permissions; these default permissions are controlled by the umask (user mask) system variable. Often, the default permissions are far in excess of what is needed for job functions, such as default world read and write privileges, creating opportunities for access to sensitive files or compromise of other accounts including root.

The umask setting should be one of:

077 - Most restrictive, but may hinder some collaborative efforts.  Only the user has any access to the files he/she creates.

027 - Somewhat less restrictive.  Allows others in the user's group to read files created by the user.

022 - Less restrictive.  Allows any user to read files created by the user.

The umask value must be set in the system file /etc/default/login.

User umasks are set in the /etc/profile file (for Bourne and Korn shell users) and in the .login or .cshrc files in the user's home directory.

For files deemed sensitive or confidential, use ACLs to further refine file access permissions.

4.1.5

Employee accounts are removed in a timely manner after separation from employment.

Unnecessary accounts or accounts with unnecessary privileges create additional access paths for intruders.

Business processes should be in place which ensure that all organizational accounts are created, updated and deleted in a timely manner.

Often, and particularly in large orgainzations, software to support the above processes must be acquired.

4.2.1

Any ' r ' services such as rlogin, rsh, rexec and .rhosts files are disabled.

By using .rhosts authentication on a server, a user can permit specified users on specified machines to log in to the server without entering a password.  Thus, individual users can set security policy (without the system administrator's knowledge), potentially leading to loss of critical resources within that account, and potentially compromising the entire host.

Run the securetcpip command to disable the ‘r’ commands and deamons

A cron job should be established to periodically check for, and remove, all 'r' commands such as rlogin, rsh, rexec, rcp and .rhosts files.  This can be accomplished manually by issuing the following command:

find / \(-name .rhosts -o -name .netrc \) -print

Remove any 'r' files that are not required (rm <filename>).

If 'r' files are required, utilize a utility such as Tripwire to verify that the files are not modified.

Where .rhosts files are permitted, they should be limited to those users with a need for UNIX r-services.  This can be accomplished on a per-user basis by editing the 'rlogin=no' parameter in /etc/security/user.

.rhosts files may be effectively monitored by including them in the AIX Trusted Computing Base.

4.2.2

All user shells are listed in the /etc/shells file.

The program chsh uses /etc/shells to determine which files are valid shells when the user wishes to change their shell. A user may be able to use any file as a shell if /etc/shells does not exist.

The /etc/shells file exists and contains the names of a small number of valid shells.

4.2.3

Data files are given only the minimum access permissions necessary for operation.

World writeable data files can be changed by anyone having any access to the system. Even without malicious intent, an inexperienced user may accidentally make critical changes to sensitive data files, or inadvertently allow an intruder to gain unauthorized access.

Obtain a list of world readable and writeable files and directories by:

find /  \(-perm -0004 -o -perm -0002 \)  -print >> ey.ww

This command will search the file system for world readable and writeable files and send the contents to a local text file called "ey.ww".

Note: exact command syntax may vary from system to system. Consult the system's man page. Also, this file may have already been created in a previous review step.

Review the list for appropriateness.

Change file permissions as necessary using chmod.

4.2.4

UNIX executables (e.g. /bin/sh and /usr/sbin/netstat), shell scripts (e.g. the /etc/rc scripts) and configuration files (e.g. /etc/inittab, /etc/inetd.conf, .profile and .login) are given only the minimum privileges necessary for operation.

World writeable binaries and shell scripts can be changed or replaced with command  files to give the intruder further access, or to damage the system (a.k.a. a "Trojan horse"). In any event, inexperienced users may accidentally damage the system or make hard to trace bugs due to critical files.

Executables and shell scripts generally should not be world writeable, e.g., those in /bin,  /usr/sbin, /dev, (although some devices may need to be world writeable), /etc, /etc/conf, /etc/default, /etc/init.d, /etc/log, /lib, /root, /shlib. Some key system files which should not be world writeable include  /etc/passwd,  /etc/group, /etc/profile, /etc/vfstab (default boot parameters), /etc/default/fs and /etc/dfs/fstypes (file system types), /etc/initab, /sbin/init and /etc/bootrc (boot script).

Tools such as Tripwire ensure that system executables have not been tampered with.

Alternatively, the AIX Trusted Computing Base (TCB) should be expanded to include the system executables.

4.3.1

Account names and passwords are not embedded in scripts, files or applications.

If account names and passwords are embedded  in login scripts, files or applications, anyone with read access to the scripts, files or applications (e.g. using the strings command) could extract the username and password, and gain unauthorized access to the system.

Account names and passwords should not be embedded in executables or text files, including .netrc files.

4.4.1

A server  key lock facility is used (if available), and the key is removed and stored in a secure location.

Key lock facilities can prevent illicit or unauthorized use of the system.

Policies should be developed, implemented and effectively communicated concerning the procedures for the proper use of the key lock facility.

A key lock facility is used (if available) to prevent unauthorized use or removal of a system.  The key is removed and stored in a secure location.

4.4.2

The server console is physically secured within a locked facility.

With physical access to the server console, all system security can be bypassed. It may be possible for unauthorized persons to obtain confidential data located on the server, or even reboot and take control over the server giving them instant root access without a password.

Develop and implement procedures to control physical access to the system.

- Servers should be located in locked rooms with physical access restricted to authorized personnel.

- Key or card access to these rooms should be limited to those who have a job requirement to enter the room frequently.

- Visitors and vendors should be escorted at all times.

- Closed-circuit surveillance of the server room entrance should be considered.

4.4.3

The system key lock is in the secure position.

Without this preventive measure, anyone with physical access to the server could cause it to reboot off of any tape, diskette, CD-ROM or hard drive, potentially allowing access to all information stored on the server.

Ensure that the system key lock is in the secure position and that the key is removed and securely stored.

4.4.4

The server's physical surroundings are designed for the safety and availability of the system, including  cleanliness (lack of dust), appropriate and stable temperature and humidity, and neat and controlled cabling.

If a computer is not stored in a clean, cool environment, it may be subject to more breakdowns and loss of data.

Rooms containing critical servers should be climate-controlled.

If conditions are inappropriate, take steps to correct.

5.1.1

Access to the Crontab command is limited.  Best practices call for only the root user to have access.

The crontab command submits, edits, list, or remove cron jobs. A cron job is a command run by the cron daemon at regularly scheduled intervals. The crontab program is owned by root and run with the SUID bit set. By default, everyone on the system can use the crontab command.

Review (using cat) the files cron.allow and cron.deny, which control access to crontab. The files must be owned by root and members of the sys group, with permissions mode 640. Under AIX, the crontab access files are /etc/cron.d/cron.allow and cron.deny. The cron.allow file is checked by the system first. This file must include all of the login names (one name per line) of users allowed to use the crontab command. The root user's login name (root) must be listed in the cron.allow file. The cron.deny file must be used to list the login names of users who are not allowed to use crontab. If neither the cron.deny nor the cron.allow file exists, only the superuser can submit a job with the crontab command.

To allow root only, remove the two files:

/var/adm/cron/cron.deny

&

/var/adm/cron/cron.allow

Where necessary, add appropriate entries to the cron.allow and cron.deny files.

To explicity allow a user to use crontab:

·        touch cron.allow

·        put the userid in it

To explicitly deny a user:

·        touch cron.deny

·        put the userid in it

5.1.2

Idle/inactive terminals are automatically locked or logged out after a period of inactivity.

If accounts are not logged out (e.g. if the user doesn't log out at lunchtime or the end of the work day) someone with physical access to a terminal can gain access to sensitive information or install backdoors allowing later access to the account.

Idle or inactive terminals should be automatically logged out after 5-20 minutes of inactivity, depending on business needs and work patterns. (TMOUT variable for the Korn shell, TIMEOUT for the Borne shell)

6.1.1

Membership in privileged groups is limited to users with a business necessity for such access.

Accounts listed in privileged groups, such as GID=0, have access to group writeable files created and owned by the root user.  Allowing unauthorized users to have a  GID=0 increases the risk that sensitive system configuration files will be changed or deleted.

Only necessary and authorized users belong to privileged groups. Membership in privileged groups should be limited to users with a business need for the access.  Of particular concern on AIX are the admin, adms and audit groups, whose menbership should be tightly controlled. For the predefined AIX groups, users should be added to the staff group only, or locally created groups.

6.1.2

Regularly examine group definitions.

A common exploit is for an attacker to modify group permissions and privileges so that their activities are possibly less noticeable to the system administrator.

To examine user group definitions, use:

/usr/sbin/lsgroup `-fa` `id` `users` `ALL`

6.1.3

Regularly examine user information.

A common exploit is for an attacker to modify group memberships for cracked accounts so that their activieites are possibly less noticeable to the system administrator.

To examing user information, use (single command):

/user/sbin/lsuser `-fa` `id` `groups` `home` `auditclasses` `login` `su` `rlogin` `telnet` `ttys` `ALL`

6.1.4

SUID and SGID programs are used only when no other reasonable, more secure means exists for the function. Where such programs are necessary, they are implemented in a secure manner, including limiting access to such programs using group permissions.

If the SUID bit is set in the file permissions,  the program executes with the permissions of the owner of the program in addition to the user executing it. For example, ps, the process status program, is SUID to root because it needs to read from system memory, something normal users are not allowed to do. The SGID bit behaves in exactly the same way as the SUID bit, except that the program operates with the permission of the group associated with the file. A vulnerability in a SUID root program (e.g.) can lead to a root-level compromise of the system. Accordingly, world writable SUID programs are especially dangerous.

Where SUID or SGID programs are necessary, restrict access to SUID and SGID programs by creating a group especially for that program. This group should have execute permissions, while 'world' should not have access to the program.  The permission bits on such a program would look like:

r-sr-x- 1         root     print     9872     Dec 28 17:44         print_cleaner

SUID programs should NOT be shell scripts, but should be compiled from C or a similar language.

6.1.5

Disable direct logins for root.

Allowing for someone to log in directly as root is dangerous because it removes a layer of authentication and it may be more prone to a sniffing attack to capture the password.

Set ‘User can LOGIN REMOTELY? = false’ in SMIT CHANGE/SHOW User Characteristics Screen.

6.1.6

If the system contains particularly sensitive data, or if strong controls on privileged access are otherwise required, software controls exist to manage and limit root access.

Root access gives complete control over the system, including the power to crash the system or erase all data. While AIX is not equipped by default with exceptionally strong controls on root activity, such controls are available where necessary, in the form of free software such as sudo and larger packages such as SeOS, CA or Tivoli Security Management. These packages allow you to restrict which commands root can run, and to log the activity of root users.

Utilize the Administrative Roles feature to achieve greater separation of duties and to reduce the number of personnel requiring the root account access.

Use a third-party facility to further partition root functionality, if required.  For example, "sudo-root" accounts can be set up and used by system operators to do system backups without providing full root functionality.

For sensitive data files, use ACLs to implement refined access controls.

If sudo is not in use, inquire about the appropriateness of using sudo.

Keep root users to a minimum.

To see which userids each user can use with su, use:

lsuser –f ALL

6.2.1

If the system contains particularly sensitive data, or if strong controls on privileged access are otherwise required, software controls exist to manage and limit root access.

Root access gives complete control over the system, including the power to crash the system or erase all data. While AIX is not equipped by default with exceptionally strong controls on root activity, such controls are available where necessary, in the form of free software such as sudo and larger packages such as SeOS, CA or Tivoli Security Management. These packages allow you to restrict which commands root can run, and to log the activity of root users.

Utilize the Administrative Roles feature to achieve greater separation of duties and to reduce the number of personnel requiring the root account access.

Use a third-party facility to further partition root functionality, if required.  For example, "sudo-root" accounts can be set up and used by system operators to do system backups without providing full root functionality.

For sensitive data files, use ACLs to implement refined access controls.

If sudo is not in use, inquire about the appropriateness of using sudo.

Keep root users to a minimum.

To see which userids each user can use with su, use:

lsuser –f ALL

7.1.1

A regular program of logging and monitoring is in place.

Logging and monitoring is often ignored or under utilized by system administrators, as it is often given a low priority by both IS and other departments. However, it is the only way to ensure the effectiveness of security measures, provide the opportunity to react to security breaches, and collect evidence of potential intrusions.

A program of logging and monitoring is in place which includes real-time monitoring and notification of potential intrusions.

7.1.2

Log files are not world writeable.

Log files provide the system audit trail and must be properly protected from unauthorized modification.

Log files, including syslog and messages, should not be writable by users other than root.  Change permissions using the command

chmod go-w syslog

7.1.3

The loginlog is not world writeable.

If the loginlog is world writeable, a intruder may delete records of their attempts to gain access, decreasing the likelihood that that their activities will be discovered.

The loginlog should not be writable by any user other than root.

Change permissions using the command

chmod go-w loginlog

7.2.1

The "sticky bit" is set on all world-writeable public directories.

If the sticky bit is not set on a world-writable directory, files in that directory may be renamed or removed by users other than the owner of the directory or file.  Some applications  create temporary files in public directories; if the sticky bit is not set, an intruder might be able to overwrite the temporary files and compromise the application.

The sticky bit should be set on all public directories which are normally world-writable, such as /tmp, /usr/tmp (/var/tmp) and /usr/spool/uucppublic. Set the sticky bit using chmod +t <name>.

No sensitive or confidential information should be written to files in these directories, since any user can read them.

7.3.1

Error logging should always be active.

Many times, security exposures happen because of errors made. Recording and reviewing these errors can reduce the exposure they potentially represent.

Ensure error logging is active ( the errdemon is running) and review the error log regularly.

7.3.2

Examine failed logins frequently.

Failed logins can be an indication of possible attack against the system.

Use the command:

/usr/bin/who ‘-s’ ‘/etc/securtiy/failedlogin’

to generate a list of usernames that are unsuccessfully used to access the system.

8.1.1

Root login is restricted to the console.

If root login is not restricted to the console, then the list of intruders who may attempt to directly gain root access increases from only those with physical access to the system to (potentially) anyone in the world. Users may still login to an unprivileged account and su to root.

Remote logins as root are not permitted.

8.1.2

.netrc files are implemented securely.

.netrc files can be a source of security risk because of the authentication information they contain.  The $HOME/.netrc file is used by the ftp and rexec commands to allow automatic login to remote hosts  without specifying passwords, and contains a list of host names, login names, and unencrypted passwords and other information to use at the remote hosts.  This gives anyone with read access to the .netrc file (root on the local host) the ID's and passwords of remote systems.

Forbid the use of .netrc files unless they are absolutely necessary (e.g.: the risk of disseminating remote passwords is acceptable).

To prevent the use of .netrc files, adhere to the following standards:

1.  They should not contain passwords,

2.  They should be 0 bytes, and

3.  They should be owned by root.

8.1.3

Users such as root, as well as various system accounts, are not allowed to use FTP.

Use of FTP access through the root account allows an additional remote path to supervisor level access by an intruder. Allowing FTP from system accounts (such as bin, smtp and sys) which normally would not require FTP also create additional paths into the system without providing an offsetting business benefit.

Using a text editor, edit the file /etc/ftpusers.  To disable ftp access for a particular account, add the name of the account to the file.

8.2.1

Use NFS only when necessary.  Check regularly for unauthorized NFS activation and use.

The NFS service allows for users to mount a systems filesystems remotely.  This service is a common way to exploit a system and gain access to private information.

To check current NFS status use:

lssrc –g nfs

To check if NFS is installed, use:

lslpp –l | /bin/grep nfs

To check if NFS is active, use:

lssrc –g nfs | /bin/grep active

To display which directories are exported, use:

cat /etc/xtab

To display which hosts are exporting directories, use:

/usr/bin/showmount

If the host is a client, to show what’s mounted from remote systems, use:

mount | grep –v “^ ”

8.2.2

File systems are not mounted writeable, absent a compelling business justification. Executables are mounted read only, if at all.

The default configuration of NFS is to grant full access (read, write and execute) to all hosts to a mounted file system. Thus there is a high chance of allowing access to unauthorized individuals.

Unauthenticated access to server executables can lead to numerous security vulnerabilities due to flaws in the mounted programs. Program coding mistakes which can become security exploits exist (whether publicly known or not)  in as many as 50% of programs.

The access control options, and recommended settings for the /etc/export and etc/dfs/dfstab files are:

-ro=host, host - Exports the directory read-only. If this option is not specified, the directory is exported with read-write permission,

-access=host,host - Restricts access to only the named hosts or netgroup name. If no -access option is specified, all hosts will have access. The default value allows any machine to mount the directory,

-rw=host,host - Exports the directory read-write. This mode of exporting inherently lowers directory security and must be implemented with caution,

-root=host,host - Allows superuser access from the named hosts. If NFS root access is not enabled for a remote NFS client, the root UID of the server is mapped to a default UID of -2 or 60001 (the nobody account) This restricts access against the superuser UID on a remote machine. Exports specifying root access are inherently less security and must be implemented with caution. The default is for no hosts to be granted root access.

-secure - Requires NFS clients to use a more secure protocol when accessing the directory.

Export only to fully-qualified host names to prevent spoofing.

Revise where inappropriate.

Use ACLs to implement refined access controls; however, if it is a heterogeneous environment, do not use ACL functions

8.2.3

NFS exported file systems are protected with access lists.

Entering a directory or filesystem in the /etc/exports file without specifying an access list allows any host to mount the directory.

NFS should be configured to allow for the minimum access necessary.  The number of servers allowed to mount an exported file system whould be reduced to the minimum necessary.  If the /etc/exports file does not specify a list of hosts for each exported file system, then NFS is insecurely configured.

Additionally, do not use the 'root=' option unless absolutely necessary.

8.2.4

NFS mounted files and directories are configured with appropriately secure file permissions.

If individual file permissions in NFS mounted shares are not configured for security, the likelihood that unauthorized users will have access to sensitive information increases.

Files and directories on the server should be protected by setting their owner to root and their protection mode to 755 (in the case of programs and directories) or 644 (in the case of data files).

8.3.1

Network services, including login, telnet, FTP, and HTTP do not display system identifying banners prior to authentication. Instead, a warning message displays a warning against unauthorized use.

Servers often display sensitive information by default, such as the hostname, the OS version, and the server software version, e.g. ftp.clienthost.com, AIX4.3.3, wuftp version2.14(b9). An intruder could then attempt to exploit known vulnerabilities in these software types (available from public Internet databases). Legitimate users generally do not need to know such information. A warning message may also be necessary for subsequent prosecution of offenders.

Instead of banners that identify system type and other sensitive information, network services display generic warning banners.

8.3.2

Only necessary network services are enabled. Where necessary, services are only implemented in a secure manner, including IP filtering, TCP Wrapper, and installation with the latest software patches.

Unintended network access can be granted by computers that have more services enabled that is necessary. UNIX systems often are configured "out of the box" with numerous network services that are often unneeded, such as the Berkeley R commands (rshell, rexec and rlogin) and  obsolete network testing services such as echo, discard and chargen. After installation, system administrators will often install unnecessary services, because they, or their managers, underestimate the security concerns involved.  If a service is not enabled, it cannot be used to break in to the system.

Remove all unnecessary services by commenting them out of the inetd.conf file (restarting the inetd process is required at this point (kill –HUP <pid>) or out of the appropriate boot script, as necessary (by placing a comment mark (#) at the beginning of the lines describing the service).

To verify inet services running use:

netserv –s –S -X

8.3.3

Rlogin and rshell are used only if an approved business justification exists.

Rlogin and rsh provide remote virtual terminal and remote execution services similar to Telnet and rexec. However:

a. rlogind and rshd do not require that the user type his login name; the login name is automatically transmitted at the start of the connection.

b. If the connection comes from a trusted host (via hosts.equiv) or trusted user (via .rhosts), rlogind and rshd will accept the connection without requiring a password.

The use of rshd and rlogind is not allowed unless a viable business justification exists.  Employ secure methods for remote shells and remote logins that include advanced authentication and encryption (e.g., Secure Shell- SSH).

8.3.4

Tftpd is disabled except on servers which act as a boot host.  On these servers, tftp is configured securely.

The Trivial File Transfer Protocol (TFTP) is used to allow users to retrieve files without requiring an account on the remote system. TFTP is an unauthenticated file transfer service. It is commonly used for booting diskless workstations and downloading server code or fonts for X-terminals over the network. Many implementations of TFTP have security problems. In particular, unrestricted TFTP access allows remote intruders to retrieve a copy of any world-readable file without authentication, such as /etc/passwd.

If TFTP is required, restrict access to server files so that sensitive files can not be retrieved remotely via tftp.  You may want to talk to Chris Watson regarding this.  He may have some stuff that could help us improve this section.

8.3.5

The finger daemon is only used if an approved business justification exists, and then only in a secure manner.

The Finger daemon service allows a remote user to obtain information about local  users, such as their  user name, full name, home directory, last login time, and in some cases when she last received and/or read her mail. The fingerd program allows users (and intruders) on remote hosts to obtain this information.

If the finger service is necessary, a newer version should be run which requires that a user name be provided along with any request.  This keeps arbitrary outsiders from obtaining a complete list of users logged in to the server.

8.3.6

The FTP daemon is only used if an approved business justification exists.

The File Transfer Protocol (FTP) allows users to connect to remote systems and transfer files. FTP may be used in either authenticated (where a plaintext username and password are required) or anonymous (no username or password required) mode, depending on system configuration. In either case, FTP allows remote access to the server’s files, without secure authentication. FTP is an issue both because it allows remote users access to the file system and because legitimate users have been known to unwittingly store sensitive corporate information on publically available FTP sites.

If FTP is required, it should be enabled with the following standard:

1.  Only the latest release (including patches) should be used, as various FTP servers have security bugs that allow intruders to break into the system,

2.  Anonymous FTP is not allowed, and

3.  The /etc/ftpusers file is utilized to restrict login from defined accounts.

8.3.7

The remote printer daemon is securely configured.

The /etc/hosts.lpd file is used to specify the remote hosts that are allowed to communicate with the lpd printer daemon and access local printer queues. An improper configuration can lead to unauthorized root access.

Edit the hosts.lpd file as necessary, using a text editor.

Change file permissions using:

chmod 640 /etc/hosts.lpd

8.3.8

The Rexec daemon is only  used if an approved business justification exists.

The rexec (RPC remote program execution) allows users to execute commands on remote computers without prior authentication.

The use of rexecd is not allowed unless a viable business justification exists.  Employ a  secure methods for remote command execution that employs advanced authentication and encryption (e.g., Secure Shell- SSH).

8.3.9

The Telnet daemon is only used if an approved business justification exists.

Telnet provides remote virtual terminal service similar to that provided by a dial-up modem. Usernames and passwords are susceptible to sniffing, as they are transmitted in plaintext. On the other hand, even without a known username and password, telnet is susceptible to remote attack. Because it is significantly faster to connect with telnet than it is to call up with a modem, an attacker can try to guess more passwords in a given amount of time. Also, it is often easier (and less expensive) to call a computer anonymously on the Internet than over the phone lines.

If telnet functionality is needed, the standard telnet server is replaced with a program which encrypts passwords, such as ssh.

Limit access to those accounts with a business justification through the accounts’ LOGIN REMOTELY fields.

8.3.10

UUCP is only  used if necessary for an approved business purposes.

All versions of UNIX provide a rudimentary form of networking called UUCP, which allows files and electronic mail to be transferred, as well as remote command execution. Installation of the UUCP subsystem is not recommended: a) there is no pairing of a single individual with a UID on UUCP, b) many UUCP systems are configured with anonymous logins. Unless UUCP is carefully configured, sensitive information can be stolen and files can be sent to your system that can compromise security.

UUCP can be disabled by changing the 'home directory' and 'shell' fields of the uucp passwd file entry to '/dev/null'.

Disable UUCP-related commands such as uucp, uulog, uuname, uupick, uusend, uustat, uuto, uux, as well as commands in /usr/lib/uucp (Note that the uuencode and uudecode commands should not be disabled, as they are used by other applications such as mail clients. However, make sure that uuencode is not SUID, or else the user could accidentally create SUID executables).

8.3.11

X Windows is only  used if necessary for an approved business purposes. If required, it is implemented in a secure manner, using secure shell to encrypt X traffic.  Lets either use Xwindows or X Windows.

We need to have “Impact(s)” discussed.

If X windows is not needed, it should be disabled by editing the AIX rc startup files and commenting out the line which starts X windows.

If X windows is needed, it may be configured to use an encrypting "tunnel"  such as Secure Shell.

8.3.12

Direct modem access to servers is only used if necessary for an approved business purpose; if necessary it is implemented in a secure manner.

It is not uncommon for systems to be configured with insecure direct modem access, either “out of the box” or thereafter by non-security conscious administrators. Dial-up modems allow anyone who knows the correct telephone number to access the system and try to break in. For example, it is not uncommon for the modem to have no password, or a simple password such as “guest”. Also, if improperly configured, modems may allow an attacker to call a system and obtain access to an already logged-in line that another user has unknowingly left behind.

Several options are available for increasing modem security.

If practical, dial-back modems should be used.

Hardware tokens is a secure way of providing remote access, and should be used if at all possible

8.3.13

hosts.equiv files are not used to establish trust relationships.

The file /etc/hosts.equiv is used to establish global, password-less trust relationships between remote systems and the server, similar to .rhosts files (the system actually checks hosts.equiv first, then .rhosts if no matches are found).

/etc/hosts.equiv files are not used to establish trust relationships between hosts.

No application should need unauthenticated access to another server.  If such applications exist and are mission-critical, they should be configured to make narrow use of the .rhosts feature of AIX while alternative applications are investigated or developed internally.