AccessibilitySkip to Top NavigationSkip to Main ContentHome  |  Contact IRS  |  About IRS  |  Site Map  |  Español  |  Help  

Part 10. Security, Privacy and Assurance

Chapter 8. Information Technology (IT) Security

Section 10. Basic UNIX Security Requirements (BUSR)

10.8.10  Basic UNIX Security Requirements (BUSR)

10.8.10.1  (09-19-2007)
Purpose

  1. This IRM establishes security policy and requirements for all UNIX and Linux operating systems within the IRS.

10.8.10.1.1  (12-21-2007)
Policy Overview

  1. This IRM establishes the minimum mandatory security settings for all UNIX and Linux operating systems within the IRS.

  2. This IRM is not predicated on definitions of GSSs or applications. The IRM is specific to the computer platforms and their operating systems regardless whether they are a GSS or part of a GSS or part of a major application.

10.8.10.1.2  (12-21-2007)
Scope

  1. The provisions in this IRM apply to all offices, business, operating and functional units within the IRS, external trading partners, as well as vendors with contractual arrangements with IRS, that use or operate UNIX or Linux systems which contain IRS data.

  2. This IRM also applies to individuals and organizations having contractual arrangements with the IRS, including employees, contractors, vendors, and outsourcing providers, which use or operate UNIX or Linux Information Technology (IT) systems containing IRS data.

  3. This IRM contains requirements (some in the form of security configuration settings) for any UNIX or Linux operating systems within the IRS and any UNIX or Linux subsystem of another operating system. This IRM applies to any UNIX regions or subsystems installed on IRS mainframes, applies to vendor-specific UNIX variants such as IBM AIX and HP’s HP-UX.

  4. Contact Cybersecurity for additional information concerning requirements for relational databases installed on hosts covered by this IRM, and are not addressed within this IRM.

  5. Contact Cybersecurity for additional information concerning requirements for web server or web application software installed on hosts covered by this IRM and are not addressed within this IRM.

10.8.10.1.3  (12-21-2007)
IRM Section Topics

  1. This IRM contains information on the following subjects:

    • Authority;

    • General Policy;

    • Management Controls;

    • Operational Controls;

    • Technical Controls;

    • Deviations;

    • Access Enforcement Requirements ( See Exhibit 10.8.10-1)

    • Solaris Specific Settings ( See Exhibit 10.8.10-2)

    • Glossary ( See Exhibit 10.8.10-3)

    • References ( See Exhibit 10.8.10-4.)

10.8.10.1.4  (12-21-2007)
Authority

  1. This IRM supplements the requirements of IRM 10.8.1, Information Technology (IT) Security Policy and Guidance.

  2. This IRM provides additional detailed requirements and is not to contradict nor alter the meaning of requirements stated in IRM 10.8.1.

  3. In the event there is a discrepancy between this IRM and IRM 10.8.1, IRM 10.8.1 has precedence unless specifically noted otherwise.

10.8.10.2  (12-21-2007)
General Policy

  1. All requirements in the main body of the document apply to all IRS UNIX and Linux operating systems generally, regardless of vendor product or version.

    1. IRS Requirements specific to a particular product, such as Sun Solaris, Linux, etc., are covered in individual exhibits in this IRM.

    2. UNIX-based operating systems not specifically covered in this IRM shall be secured according to the general guidance of this IRM as well as vendor-recommended security configurations and the application of all vendor-supplied security patches. All guidance from the vendor supplements this IRM, where it is not in contradiction.

  2. System Administrators (SAs) shall ensure the operating system version is a version for which the vendor still offers standardized technical support and is in accordance with IRS Enterprise Architecture (EA) Enterprise Standards Profile (ESP) that dictates the official products and versions of software within the IRS.

  3. Restrictions as specified in this IRM by sections Restrictions on Superuser Access, and Least Privilege, shall be strictly observed.

10.8.10.2.1  (12-21-2007)
Roles and Responsibilities

  1. The IRS shall implement security roles in accordance with Federal laws and IT security guidelines (e.g., Federal Information Security Management Act (FISMA), National Institute of Standards and Technology (NIST), Office of Management and Budget (OMB), Treasury) that are appropriate for their specific operations and missions.

  2. For further information, see IRM 10.8.2, Information Technology (IT) Security Roles and Responsibilities.

10.8.10.2.2  (12-21-2007)
Restrictions on Superuser Access

  1. Only individuals assigned the full set of SA responsibilities, as defined by IRM 10.8.2, shall be permitted shell access as "root" or similar superuser accounts on all systems covered by this IRM, including test and development systems.

  2. See section titledLeast Privilege of this IRM for additional requirements and explanation related to restrictions on superuser access.

  3. See section titledFire Call Procedure of this IRM for policy and requirements regarding emergency use of superuser privileges.

10.8.10.3  (12-21-2007)
Management Controls

  1. Management controls focus on the management of risk for an application or system and the management of computer security controls to mitigate that risk. See IRM 10.8.1 for general information and computer security management control requirements.

  2. Additional management controls specific to UNIX systems are provided below in the following area, Planning:

10.8.10.3.1  (12-21-2007)
Planning

  1. SAs shall participate in contingency planning and contingency plan testing activities, as specified by IRM 10.8.1.

  2. SAs shall participate in audit logging plan development. See IRM 10.8.3.

  3. SAs shall plan for and schedule appropriate system maintenance activities necessary to bring systems into compliance with this IRM.

    1. SAs shall apply vendor recommended security patches to operating systems within 30 days from the issuance date of the security patches from the vendor, or more frequently if stipulated by the IRS Computer Security Incident Response Center (CSIRC) policy.

    2. SAs shall upgrade applications having known security vulnerabilities, such as Berkeley Internet Name Domain (BIND) and sendmail, to currently supported versions within 90 days of issuance. See section titled Application Configuration Restrictions of this IRM for more detail.

    3. SAs shall initiate planning, migration, and coordination activities to replace insecure system utilities such as telnet and FTP with utilities that provide session encryption. See section titled Network Service Restrictions of this IRM for additional detail.

    4. SAs shall initiate necessary planning and coordination activities to remove superuser shell access from non-SAs, per section titled Least Privilege of this IRM, and replace such access with utilities that delegate limited superuser privileges as described in that section.

    5. Systems administrators shall perform planning, migration, and coordination activities to replace use of Network File Systems (NFS) technology with a more secure alternative. See section titled Network File System (NFS) of this IRM for additional detail.

10.8.10.4  (12-21-2007)
Operational Controls

  1. Operational controls address security mechanisms that primarily are implemented and executed by people as opposed to systems. They often require technical or specialized expertise and rely on management activities as well as technical controls. See IRM 10.8.1 for general information and computer security operational control requirements.

  2. Additional operational controls specific to UNIX systems are provided below in the following areas:

    1. Contingency Planning

    2. Configuration Management (CM)

    3. Maintenance

    4. System and Information Integrity

10.8.10.4.1  (12-21-2007)
Contingency Planning

  1. SAs shall participate in contingency planning and contingency plan testing activities, as specified by IRM 10.8.1.

  2. SAs shall backup a baseline of each system (as defined in section titled Baseline Configuration of this IRM) to write-protected media.

10.8.10.4.2  (12-21-2007)
Configuration Management (CM)

  1. Configuration Management (CM) requirements for all systems covered by this IRM follow below. The requirements below supplement the general CM requirements established by IRM 10.8.1.

  2. Refer to IRM 10.8.1 for other applicable CM requirements.

10.8.10.4.2.1  (12-21-2007)
Baseline Configuration

  1. System owners are responsible for ensuring that a common minimum operating system baseline configuration is established and maintained for all hosts within the system owner’s boundary.

  2. SAs shall ensure that the common minimum operating system baseline contains a minimum number of necessary network services, as specified in section titledNetwork Service Restrictions of this IRM.

  3. SAs shall ensure that the common minimum operating system baseline includes configuration restrictions for common applications provided with the operating system, as specified in section titledApplication Configuration Restrictions of this IRM

  4. SAs shall ensure all products and devices shall be installed following MITS standards.

  5. SAs shall configure separate file system partitions for /export/home, /var, /var/audit, and /opt.

  6. SAs shall ensure the root shell is located on the root file system.

  7. SAs shall create and populate the following inventory file, and save the file under the file name /etc/serverinfo.conf.

    1. GSS identifier: The GSS for which the host is assigned.

    2. POC information: The name of the primary or lead SA for the host, and the SA’s telephone and electronic mail contact information.

    3. Server Type: The type of server the system functions as. Valid values are 'Development' and 'Production'. If the server type is not specified, 'Production' is assumed.

    4. ServerRole attributes: These roles specify the functionality required by IRS business units (i.e., business unit end users or business applications) to support business processes and applications. Uncomment each line for functions that are applicable. For example, if a business application has a requirement to use sendmail for incoming or outgoing electronic mail, uncomment the "ServerRole=Mail" line.

    # UNIX Server Configuration Information
     
    # The GSS that owns this server:
    GSS=##
     
    # The primary SA Point of Contact (POC):
    POCName=First Last
    POCPhone=(###) ###-####
    POCEmail=First.Last@irs.gov
    #The type of functionality provided by this server (valid values: 'Production' or 'Development') ServerType=Production
    # Business-required functionality provided by this server (uncomment all that apply)
    #ServerRole=Mail
    #ServerRole=WebServer
    #ServerRole=DNSServer
    #ServerRole=DatabaseServer
    #ServerRole=AppServer
    #ServerRole=NISclient
    #ServerRole=NISServer
    #ServerRole=NFSServer
    #ServerRole=PublicServer
    #ServerRole=XWindows
    #ServerRole=SambaServer

10.8.10.4.2.2  (12-21-2007)
Monitoring Configuration Changes

  1. SAs shall create and maintain a system baseline listing of cryptographic hashes of all device files, sgid and suid files, system libraries and binaries using tripwire or a similar utility. System baseline shall be made available to the Security Specialist (SecSpec).

  2. SAs shall generate a new system baseline listing after every software change and after changes to system directories and files are applied.

  3. SAs shall ensure all local filesystems are checked at least weekly against the system baseline to detect any unauthorized suid or sgid files or unauthorized modification to authorized files.

  4. The SAs and system owner shall comply with the security change management requirements of IRM 10.8.1, including use of formal written change requests to document system changes.

10.8.10.4.2.3  (12-21-2007)
Configuration Settings

  1. SAs shall ensure that configuration settings for network services are restricted as specified in section titledNetwork Service Restrictions of this IRM.

  2. SAs shall ensure that configuration settings for common applications provided with the operating system are restricted as specified in section titled Application Configuration Restrictions of this IRM.

  3. SAs shall ensure that file and directory permissions for key operating system files are set in accordance with section titled Access Controls of this IRM.

  4. SAs shall ensure the ‘nolargefiles’ option is not invoked to enable the OS to support files greater than 2 gigabytes.

10.8.10.4.3  (12-21-2007)
Maintenance

  1. The SA shall schedule maintenance activities to bring host systems into compliance with this IRM, as described in section titled Planning, and throughout this IRM.

10.8.10.4.4  (12-21-2007)
System and Information Integrity

  1. The SA and system owner shall ensure a host-based intrusion detection tool is implemented, per IRM 10.8.1.

  2. The SA shall ensure methods used to check file integrity also notify the SA via e-mail, if a security breach or a suspected security breach is discovered.

  3. The SA shall ensure all local filesystems will be checked at least weekly against the system baseline, as described in section titledBaseline Configurationof this IRM, to detect any extraneous device files and to verify system and other critical files have not been modified without proper CM documentation.

  4. System core dumps shall be prohibited on production systems.

10.8.10.5  (12-21-2007)
Technical Controls

  1. Technical controls focus on the security controls that the computer system executes. These controls provide automated protection from unauthorized access or misuse, facilitate detection of security violations, and support security requirements for the systems or applications. The implementation of technical controls should be consistent with the management of security within the organization. See IRM 10.8.1 for general information and computer security technical control requirements.

  2. Controls described in this section pertain to all systems covered by this IRM, including test and development systems.

  3. Additional technical controls specific to UNIX systems are provided below in the following areas:

    1. Identification and Authentication

    2. Access Control

    3. Audit and Accountability

    4. System and Communications Protection

10.8.10.5.1  (12-21-2007)
Identification and Authentication

  1. SAs shall change all default passwords at the time of system installation. These include, but are not limited to:

    1. Any other accounts provided by the operating system vendor (including sys, bin, and others).

    2. All default application passwords.

    3. All SNMP related passwords (read-community, write-community, etc).

  2. The SA shall ensure for all user accounts and service/daemon accounts the following are adhered to as specified in IRM 10.8.1 (with the exception of locked service accounts):

    1. Password strength requirements

    2. Password aging/expiration requirements

    3. Password length requirements

    4. Password history requirements

    5. Account lockout requirements

  3. The SA shall ensure all UNIX hosts are configured to require the root password for access to single-user and maintenance modes.

  4. The SA shall ensure logon capability to default system accounts (e.g., bin, lib, uucp, sys, guest, daemon, and any account with 'SVC' in their GECOS field) is disabled by making the default shell /bin/false,/usr/bin/false, /sbin/false, /sbin/nologin, or /dev/null and by locking the password.

  5. The SA shall ensure the logon delay between logon prompts after a failed logon is set to at least three seconds.

10.8.10.5.2  (12-21-2007)
Access Control

  1. Access controls for network services shall be restricted as specified in section titled Network Service Restrictions of this IRM.

  2. Access controls for common applications provided with the operating system shall be restricted as specified in section titled Application Configuration Restrictions of this IRM.

  3. The SA shall ensure all files have a designated owner and group defined in /etc/passwd and /etc/group. See Exhibit 10.8.10-1, Appendix A, Part A.1, (2) table for required file ownerships.

  4. Refer to section titled Access Enforcement of this IRM for more detailed requirements.

  5. Banner settings shall be followed as specified in IRM 10.8.1 for the following (note that even disabled services must be configured to policy):

    1. console

    2. SSH

    3. Telnet

    4. ftp

10.8.10.5.2.1  (12-21-2007)
Least Privilege

  1. All users of systems covered by this IRM shall be given the minimum system privileges necessary to accomplish their official duties, per IRM 10.8.1.

  2. Only officially assigned SAs (as defined in IRM 10.8.2) shall be permitted shell access as "root" or similar superuser accounts on any systems covered by this IRM, including test and development systems.

    1. Only the root account or officially assigned SAs needing superuser privileges (superusers as noted by [SA] or [SU] in the GECOS field), shall have a User ID (UID) of 0.

    2. Only the root account and locked system accounts shall have a Group ID (GID) of 0.

    3. Only SAs shall be permitted access to the root account.

  3. Emergency access as specified in section titledFire Call Procedure of this IRM shall be the only IRM-authorized exception to (2) above regarding superuser shell access.

  4. Persons who are not SAs (as defined by IRM 10.8.2) but who have a need in their official duties to run specific programs or access specific files with superuser privileges shall use the sudo utility or an equivalent utility having a restricted interface to accomplish the required access.

    Specific examples of individuals subject to this requirement include but are not limited to the following:

    1. User administrators or other "support" personnel, whose duties involve the addition, deletion, and maintenance of user accounts.

    2. Application administrators, whose duties may involve running scripts or other programs to start and stop system processes, or install or maintain application software and affected operating system files.

    3. Database administrators (DBAs), whose duties are similar to b) above with respect to the operation and maintenance of databases.

  5. SAs shall install and configure appropriate utilities, such as sudo or an equivalent utility, on hosts as necessary to accomplish (4) above.

10.8.10.5.2.2  (12-21-2007)
Fire Call Procedure

  1. The IRS-wide policy regarding the use of Fire Call accounts for emergency system maintenance purposes is established by IRM 10.8.1. This section supplements the requirements of RM 10.8.1 for systems covered by this IRM.

  2. All uses of Fire Call accounts for systems covered by this IRM shall be documented in an approved IRS enterprise-wide problem reporting tool such as the IT Asset Management System (ITAMS).

  3. Fire Call accounts shall only be used in genuine emergencies, such as troubleshooting or restoring service to a production system. Fire Call accounts shall not be used to perform routine software installations, software upgrades, or other routine application, database, or system maintenance.

  4. Uses of Fire Call accounts shall, by default, be limited to 48 hours. If an emergency situation requiring use of a Fire Call account extends beyond 48 hours, problem reporting tool tickets as noted in (2) above shall be updated to indicate that the Fire Call account is still in use beyond the 48 hour limit.

  5. SAs shall change the password to a Fire Call account immediately after an emergency situation subsides, or no later than two (2) business days. Furthermore, SAs shall update the "sealed envelope" Fire Call password information following each change to the Fire Call password.

  6. In emergency troubleshooting situations, the Information System Owner of a production host may authorize a limited number of developers temporary access to a production database for a fixed number of days, all in accordance with OL5081 process. The approval of such access must be in writing and must be issued by an Information System Owner management-level official. The duration of the temporary access shall be specified in writing, and shall not exceed fifteen (15) days. If developer access to a production host for a period of greater than 15 days is required, a formal deviation request (to deviate from this IRM) shall be submitted in accordance with the deviation process described in section titled Deviationsof this IRM.

10.8.10.5.2.3  (12-21-2007)
Separation of Duties

  1. SAs shall ensure that no developer accounts are used on production hosts.

  2. SAs shall implement restrictions on superuser access, as described in sections titledRestrictions on Superuser Access and Least Privilege of this IRM.

10.8.10.5.2.4  (12-21-2007)
Account Management

  1. All SAs shall have two login accounts: A personal, unprivileged, "regular user" account, and a separate superuser account.

  2. All initial logins by the SA shall be to the unprivileged account. Administration functions shall be accomplished by using the "su" command to switch from the unprivileged account to the superuser account.

  3. Developers shall not have permanent accounts on production systems. See section titled Separation of Duties of this IRM for details.

  4. See section titled Least Privilege of this IRM for restrictions on superuser access.

  5. The SA shall ensure the root password will be changed whenever an individual with access to the root password is reassigned, as per IRM 10.8.1.

  6. No generic FTP accounts shall exist.

10.8.10.5.2.4.1  (12-21-2007)
Account Categorization

  1. The SA shall ensure that each login account on each host includes descriptive text in the GECOS field identifying a category for the account. See the man pages for "passwd" for a description of fields in password files.

  2. Category codes for account assignments shall be documented in the GECOS field and enclosed in square brackets as listed below:

    Account Type GECOS Indicator
    'Root' account [ROOT]
    Officially Assigned SA
    (as defined in IRM 10.8.2)     		[SA]
    Database Administrator (DBA)
    (as defined in IRM 10.8.2)     		[DBA]
    Webmaster or Web Content Administrator [WEB]
    Application Administrator [APP]
    Other Superuser [SU]
    Infrastructure Auditor Accounts [AU]
    Service Account (e.g., bin, sys) [SVC]
    Interactive Service Account (e.g., sftp, oracle) [ISVC]
    Business Account (Employee) [EMP]
    Business Account (Contractor) [CTR]
    Business Account (General Public or other Non-IRS, e.g., state employee) [PUB]
    Developer Account (Employee or Contractor) [DEV]
    Testing Account (Employee or Contractor) [TST]
    Training Account (Employee or Contractor) [TRN]


    An example GECOS field entry conforming to the requirement above is as follows:

    John Smith, NCFB, 202-283-9990 [DBA]


    System owners and SAs for individual hosts may supplement the required account category information provided in the GECOS field with telephone number or other information, as illustrated above.

10.8.10.5.2.5  (12-21-2007)
Session Termination

  1. The SA shall ensure all session termination requirements are adhered to as specified in IRM 10.8.1.

10.8.10.5.2.6  (12-21-2007)
Access Enforcement

  1. SAs shall ensure no shell service listed in /etc/shells has the suid or sgid bit set.

  2. The SA shall ensure that the host has no world-writable files in file systems, except in the /dev, /proc, /devices (if used) and /selinux (if used) directories. This requirement does not apply to symbolic links, named pipes, or sockets required by the operating system or IRS-authorized applications.

  3. The SA shall ensure the remote console feature is not implemented.

  4. Direct root logins shall only be allowed from the system console. All other logins to the root account or other superuser account shall be accomplished via the "su" command.

  5. SAs shall ensure that log servers do not accept logs from hosts outside the IRS intranet

  6. The SA shall ensure .netrc, .rhosts, .shosts, and hosts.equiv files do not exist.

  7. The SA shall ensure /etc/passwd, /etc/shadow, and /etc/group files will not contain a plus (+) or minus (-) sign in the first column.

  8. The SA shall ensure device file directories will not be writable except by the owner or as configured by the vendor.

  9. The SA shall ensure removable media and remote filesystems will be mounted with the no suid option.

  10. The SA shall ensure the local UNIX host printer configuration file (/etc/lp/Systems or /etc/printers.conf) does not contain the ‘-’ (minus) or ‘+’ (plus) character.

  11. The SA shall ensure the /etc/shells file exists.

  12. The SA shall ensure all shells referenced in the /etc/passwd file are listed in the /etc/shells file. The /usr/bin/false, /bin/false, /dev/null, /sbin/nologin, /sbin/false, and sdshell will be considered valid shells for use in the /etc/passwd file, but will not be listed in the /etc/shells file.

  13. The SA shall ensure that public instant messaging clients are not installed.

  14. The SA shall ensure that peer-to-peer file-sharing applications are not installed.

  15. The SA shall ensure each group referenced in the /etc/passwd file will be defined in the /etc/group file.

  16. The SA shall ensure root is assigned the home directory ‘/root.’

  17. SAs shall assign every non-system user account a unique home directory in the /etc/passwd file.

  18. The SA shall ensure all home directories defined in the /etc/passwd file exist.

  19. Refer to Exhibit 10.8.10-1, Appendix A. Access Enforcement Requirements, Part A.1 for general enforcement requirements regarding file ownership and permissions.

  20. See Exhibit 10.8.10-1, Appendix A, Part A.2 for specifications on the use of initialization and environment settings.

  21. See Exhibit 10.8.10-1, See Exhibit 10.8.10-1, Appendix A, Part A.3 for restrictions on the use of ‘cron’ commands.

  22. See Exhibit 10.8.10-1, Appendix A, Part A.4 for restrictions on the use of ‘at’ commands.

10.8.10.5.3  (12-21-2007)
Audit and Accountability

  1. SAs shall enable and configure audit logging on all systems covered by this IRM. Auditable events shall be logged and processed as specified by Cybersecurity policy for Audit Logging Security Standards.

  2. MITS is responsible for installing and configuring an IRS-wide time server.

  3. SAs shall ensure the accuracy of the system clock and date by configuring host system clocks to synchronize with the IRS-wide or Treasury-wide time server.

  4. SAs shall ensure all logon attempts, both successful and unsuccessful, are logged to a system log file.

  5. SAs shall ensure all switch user (su) activity is recorded in a system log.

  6. SAs shall ensure the logging option is implemented for the root filesystem.

  7. SAs shall ensure audit data files and directories will be read-only. IRM 10.8.2 defines the responsibilities of SecSpecs.

  8. SAs shall ensure all users are subject to identical audit parameters.

  9. Platform specific audit logging parameter settings shall be applied as described in the exhibits to this IRM.

10.8.10.5.4  (12-21-2007)
System and Communications Protection

  1. The IRS shall monitor, control, and protect UNIX systems and communications in accordance with the following requirements.

10.8.10.5.4.1  (12-21-2007)
Network Service Restrictions

  1. The SA shall disable network services deemed unnecessary for the operation of a host.

  2. The SA shall ensure network parameters are securely set, as follows:

    • Disable source routed packets.

    • Disable system directed broadcasts with IP forwarding.

    • Do not respond to ICMP timestamp requests.

    • Do not respond to ICMP timestamp broadcast requests.

    • Do not respond to echo request broadcasts.

  3. The SA shall ensure the executable stack is disabled.

  4. The SA shall ensure systems not running routing have a default gateway defined.

  5. At a minimum, the following network services and daemons shall be disabled (with the exception of inetd logging, which shall be enabled):

    # Network Service Settings Required
    1 echo Disable
    2 netstat Disable
    3 rcp Disable
    4 chargen Disable
    5 finger Disable
    6 tftpd Disable
    7 walld Disable
    8 rstatd Disable
    9 sprayd Disable
    10 rusersd Disable
    11 rlogin Disable
    12 rsh Disable
    13 ftp Disable
    14 telnet Disable
    15 fsp Disable
    16 nfs Disable
    17 inn Disable
    18 uucp Disable
    19 rexec Disable
    20 inetd logging/tracing Enable

10.8.10.5.4.1.1  (12-21-2007)
Domain Name Service (DNS)

  1. The SA shall ensure the minimum version of BIND installed shall be version 9.3 or newer with the exception of Red Hat Linux which shall have version 9.2.4-16 or newer installed. Old versions of BIND shall be removed.

  2. System owners shall ensure DNS server software is implemented only on dedicated hardware. Specifically, other server software (e.g., web servers or databases) shall not co-reside on the same host.

  3. See Exhibit 10.8.10-1, Appendix A, Part A.1 (1) for required file permissions.

  4. See Exhibit 10.8.10-1, Appendix A, Part A.1 (2) for required file ownerships.

10.8.10.5.4.1.2  (12-21-2007)
Secure Shell (SSH)

  1. SAs shall use SSH to encrypt all Sensitive But Unclassified (SBU) network communications by all personnel.

  2. If SSH server is running, the SA shall ensure neither SSH Protocol version 1 nor Protocol version 1 compatibility mode shall be used. Additionally, the SA shall ensure Protocol 2 is listed in the sshd_config file.

  3. If SSH server is running, the SA shall ensure SSH is configured to work with TCP_Wrappers or equivalent functionality. See TCP_Wrappers section below.

10.8.10.5.4.1.3  (12-21-2007)
TCP_Wrappers

  1. The TCP_Wrappers package is a utility which allows monitoring and control over connections to TCP network protocol ports of interest (such as FTP, SSH, etc). SAs shall implement TCP_Wrappers or equivalent utility to provide this functionality.

  2. The SA shall ensure if TCP_Wrappers technology is implemented, hosts.deny and host.allow shall be used to grant or deny access to system hosts.

  3. The SA shall ensure TCP_Wrappers, or equivalent utilities, shall be configured to log each system access attempt.

10.8.10.5.4.1.4  (12-21-2007)
Simple Network Management Protocol (SNMP)

  1. The SAs and system owners shall comply with the SNMP version requirements in IRM 10.8.1.

  2. See Exhibit 10.8.10-1, Appendix A, Part A.1 (1) for required file permissions.

  3. See Exhibit 10.8.10-1, Appendix A, Part A.1 (2) for required file ownerships.

10.8.10.5.4.1.5  (12-21-2007)
Network File System (NFS)

  1. The use of NFS within production systems is not allowed (those systems that have previously completed C&A shall replac