1. Purpose

Ensuring the continuity of systems that are responsible for hosting the company’s business applications is regarded as of vital importance to our sustained competitiveness. Not only should these systems be protected against the obvious external threats, such as viruses and hackers, they should also be secured against potential, and possibly more dangerous internal “threats”. The rule is that employees should never have more privileges than is necessary for their functions. This issue can be addressed by proper configuration of the systems. Configuration of systems, however, only provides a basic security level. Adapting to the dynamic IT environment requires continuous updating through service packs, hotfixes, and security patches. Figure 1. illustrates this concept.

Figure 1. Baseline security configuration and applied updates

The procedure discussed here provides a guideline to IT personnel for configuring Windows and UNIX systems according to company IT’s requirements. Moreover, this procedure also guides IT staff through the process of updating from patch releases to company-wide dissemination.

2. Scope

The Windows and UNIX Security Configuration and Patch Update Procedure includes all Windows and UNIX systems that are (or are about to be) connected to the company’s information network. More specifically, the procedure includes all servers, workstations, and personal computers that are connected to the network. The company currently uses Sun Solaris 2.6 and Linux 9.0 for its UNIX platform systems, Windows Server 2000 for its Windows servers, and Windows 2000 Professional for its desktop PC’s

As far as updates are concerned, the Windows and UNIX Security Configuration and Patch Update Procedure includes all service packs, hotfixes, and security patches that are released and considered relevant (i.e. the update addresses or fixes an existing issue) to the organization.

3. Owner

IT Dept

4. Policy

4.1. Configuration policy

Any system connected to the network must be configured according to IT guidelines, in order to achieve a specified security configuration baseline (e.g. C2 or E2 security assurance levels). Systems that do not meet this baseline requirement must be reconfigured accordingly. Furthermore, configuration should be performed only by certified IT staff.

4.2. Updating policy

Effective updating requires the adherence to a predefined policy. The following guidelines, in accordance with IT’s best practices, must be taken into account when installing updates:

Install only updates that are relevant (i.e. updates that address an existing vulnerability of the system);
All documentation must be read prior to the decision of whether or not to install the released update;
All updates (except Service Packs) should be subjected to a risk assessment in order to determine the necessity, the impact, and timing of applying the update;
The risk of implementing the update should always be less than the risk of not implementing it;
One should never be worse off by implementing an update. If unsure, steps should be taken to ensure that there is no doubt when disseminating the update to production systems;
All updates must be tested on a representative non-production environment prior to being deployed to production;
One should ensure that the update can be uninstalled if considered necessary;
Production downtime must be scheduled to implement the update. Ensure that backup tapes and emergency repair disks are available, in case a restoration is required;
A back-out plan (see Appendix A) must be available in case an uninstall option is unavailable or failing;
Helpdesk staff and key user groups must be notified of the scheduled update;
One should not get more than two service packs behind;
Conduct phased implementation: update non-critical servers first, then target the primary production servers;
Progress and changes must be tracked for (security) audit purposes in IT’s change control/ticketing system;
Security patches must be installed within two months after vendor release;
Patches marked as “mandatory” by IT must be installed immediately after official notification.

5. Roles and Responsibilities

The Windows and UNIX Security Configuration and Patch Update Procedure involves the following roles and corresponding responsibilities.

Role	Responsibilities

Security Officer	The security officer is responsible for checking for the latest patches. The security officer is responsible for assessing the patch and preparing a patch report, which must be submitted to the site manager. The security officer is responsible for informing and aligning the new patch with IT
Application team	The application team is responsible for verifying updating the patch with vendor. The application team is responsible for arranging server downtime for the installation of patches if necessary. The application team is responsible for testing the prepared patch with PC support team or system team
System team	The system team is responsible for downloading the required patch. The system team is responsible for distributing the patch. The system administrator is responsible for the manual installation of UNIX patches. The system team is responsible for preparing the Tivoli patch package in case of Windows patches.
PC support team	The PC support team is responsible for manually installing Windows patches on systems that have been ignored by Tivoli.

6. Definition and Abbreviations

6.1. Definitions

Network: An integrated, communication aggregation of computers and peripherals linked through communication facilities.

Risk analysis: An analysis that examines an organization’s information resources, its existing controls, and its remaining organization and computer system vulnerabilities. It combines the loss potential for each resource or combination of resources with an estimated rate of occurrence to establish a potential level of damage in dollars or other assets.

Risk assessment: Synonymous with risk analysis.

Security audit: An examination of data security procedures and measures to evaluate their adequacy and compliance with established policy.

6.2. Abbreviations

ACL: Access Control List

ARM: Account Resource Management

ASET: Automated Security Enhancement Tool

IIS: Internet Information Server

IT: Information Technology

ITSEC: Information Technology Security Evaluation Criteria

LSA: Local Security Authority

NTFS: New Technology File System

OS: Operating System

PC: Personal Computer

SO: Security Officer

SVR4: System V Release 4

TCB: Trusted Computing Base

TCSEC: Trusted Computer System Evaluation Criteria

TMF: Tivoli Management Framework

7. Procedure details

7.1. Procedure definition

7.1.1. Configuring UNIX systems (SunOS 5.0)[1]

7.1.1.1. Introduction

SunOS 5.0 is SunSoft’s SVR4-based version of UNIX incorporating enhanced security and system administration. It is the foundation of the Solaris 2.0 operating environment. All versions of SunOS from Release 4.0 on are C2 compliant, but SunOS can utilize Sun’s own software add-ons, Account Resource Management (ARM) and Automated Security Enhancement Tool (ASET), to increase security to the TCSEC B1 Level, and it is currently under evaluation with TCSEC. ARM improves account protection and adds new password mechanisms, while ASET is a network security audit and management tool. SunOS also supports Secure rpc, a remote authentication tool competing with Kerberos. SunOS 5.0 offers a choice between Secure rpc, Kerberos remote authentication or ordinary UNIX authentication, whilst the Solaris 2.0 environment allows these to co-exist and offers a “federated security” approach allowing network services and applications to use different authentication mechanisms within the same network. It should be noted that use of Secure rpc is only recommended if the security requirements are such that they outweigh the performance degradation.

SunSoft intends to make federated security available to multivendor network services through the Generic Security Services API. Solaris Version 2.4SE offers additional security modules and has been evaluated to Assurance Level E2 for UK ITSEC.

7.1.1.2. Initial installation

As soon as the system is installed, set a good, secure password for root and, if required, ensure that any other accounts supplied with the system software have passwords set as well. Those accounts which will not be logged into must have the password field in /etc/shadow disabled with a “*” character. The login shell for all these accounts should be set to /bin/false (unless uucp is required, in which case the shell is /usr/lib/uucp/uucico). The system logins supplied with Solaris are the following.

Account	GID	Use

root	0	System administration. Can override all system protection mechanisms
daemon	1	Controls background processing
bin	2	Owns most of the commands
sys	3	Owns most of the system files
adm	4	Owns certain administrative files
uucp	5	Owns the UUCP subsystem files and modems if used
nuucp	9	Used by certain remote systems to log in and start file transfers
lp	71	Owns the spooler subsystem
audit		Owns the log files
nobody		Used for some network services
news		Used by uucp
sync	1

Ensure that you have the latest security patches installed on your system. Confirm this with your supplier. This should be performed on a weekly basis by the Security Officer.

Check that you have the latest version of sendmail. There should be a file called converting.sun.configs with the distribution which will enable you to convert from Sun’s sendmail.

Enable login logging using the following commands, as root.

touch /var/adm/loginlog

chmod 600 /var/adm/loginlog

chgrp sys /var/adm/loginlog

chown root /var/adm/loginlog

This file should be monitored for daily unsuccessful login attempts. Once a pattern of growth has been established it may be possible to automate the process with a cron script to check only for an uncharacteristic increase in the file size indicating a possible break-in attempt.

Sun workstations have a number of special devices built in which have been used to compromise systems in the past. These are the audio device, especially the microphone, the video frame buffer, the mouse and the keyboard. Only the root user can have access to these devices, however, the file /etc/logindevperm may contain entries which allow access to any user using the controls. These devices then have their ownership changed to that of the user. Ensure that any entry in this file is validated and that the file cannot be written to by anyone.

An example of part of the /etc/logindevperm file is shown below.

# Device	Permission	Colon separated device list
#
/dev/console	0600	/dev/kbd:/dev/mouse
/dev/console	0600	/dev/sound/*	#audio devices
/dev/console	0600	/dev/fbs/*	#frame buffers

Start up monitoring usage of the su command.

vi /etc/default/su

uncomment the line: SULOG=/var/adm/sulog Starts su logging.

uncomment the line: CONSOLE=/dev/console Displays su attempts on system console.

vi /etc/default/login

uncomment the line: CONSOLE=/dev/console This restricts root login to the console. The administrator may still su to root from their normal user account, and the event will be logged.

Set up a default umask in /etc/profile. If this is set to a secure value such as 077, then user created files will automatically be protected, however, if the users wish to share files, the permissions on those files can be explicitly changed.

Create appropriate groups for your users. Ensure that the only account with a UID of 0 is root.

Search the system for .rhosts and .netrc files and ensure that they are empty, owned by root and not writable.

find / -depth -name .rhosts -print

find / -depth –name .netrc -print

To prevent a particular type of denial-of-service attack, restrict the maximum number of processes a user can have running at once. This can be achieved by setting the following line in /etc/system.

set MAXPROC=100

Ensure that the PATH environment variable for root does not contain the current working directory “.” (dot). Check for this in all root’s shell start-up files, i.e. /.profile, /.cshrc, /.login.

Edit the file /etc/aliases and remove the entry for decode. Ensure that this file is owned by root and has permissions 0644.

The permissions on /etc/utmp must be set to 644.

Edit the file /etc/inet/inet.d and comment out unwanted rpc services, especially rexd, fingerd, systat, netstat, ruserd, sprayd and uucpd if it is not required.

Also, disable tftpd and routed.

Restart the inet daemon:

ps -ef | grep inetd

kill -HUP procnum

Enable nfs port monitoring if you are using nfs. Add the following line to /etc/system.

set nfs:nfs_portmon = 1

Or, if you are installing Solaris v.2.5

setnfssrv:nfs_prtmon = 1

In /etc/dfs/dfstab the command line should look like this:

share -F nfs –o ro=file_system_name

Mount nfs file systems with the nosuid option.

Disable IP forwarding and source routing:

Edit the file /etc/rc2.2.d/S69.inet and set the options ip_forwarding and ip_ip_forward_sec_routed to zero as shown.

ndd -set /dev/ip ip_forwarding 0

ndd -set /dev/ip ip_ip_forward_src_routed 0

Reboot the system for these changes to take effect.

7.1.1.3. TCB (Trusted Computing Base)

Run the ASET program using parameters appropriate to the particular system. It is expected that the highest security level will be chosen. The configuration files are found in the directory /usr/aset. All the initial report files (.rpt) should be copied to removable storage media and also printed out. These documents should then be securely located away from the computer room with very restricted access. This process must be repeated after major system updates or rebuilds after system failures.

Run the following command to create a base-line for the existence of files with the setuid bit set.

find / -user root -perm -4000 -exec ls -lbd {}\; > /var/adm/suidfiles

Run the command for other file systems as well and append the outputs to the file. If your version of Solaris has the ncheck command, run this also with the -s option. This has an advantage over find in that it can detect SUID files hidden below directories used as mount points.

7.1.1.4. User set-up

All users must have passwords. An account without a password can be located with the following command.

logins –p

More information may be obtained with the following command.

Passwd -s -a (only root may use these options)

Set up password ageing for all users. The maximum password life should be 60 days. There should be warnings given at login time from one week before the password expires. The command for this is:

passwd -x 42 -w 7 username

Consider installing the anlpasswd[2] utility to proactively screen passwords as they are entered, or run crack[3] regularly to enforce the use of effective passwords. See the documentation that accompanies crack for instructions on configuring with shadow password files. Ensure that you have written permission from your manager before running crack.

7.1.1.5. File Security

Scan the system for .exrc files that seem to have no legitimate purpose and delete them. This command line will find them and display the contents.

/bin/find / -name ‘.exrc’ -exec /bin/cat {}\; -print

Set up a root crontab to run ASET daily, but not during prime shift time as it is very heavy on system resources. Familiarize yourself with this utility so that you can set it up appropriately for you system.

7.1.1.6. Auditing

Enable auditing on all systems.

Set up the system log to print out to a locally connected, secure dot-matrix printer. If possible, incorporate some form of filtering such as cat -v to prevent the printer being deliberately “jammed” to mask an intruder’s activities. Ensure that the printer port is owned by root and is not world writable.

7.1.1.7. Regular activities

Passwords

Change the root password often, at least monthly, and inform only those who need to know it. Devise a secure method of disseminating the new password.

Set up new user accounts so that the password must be changed at first login. Ensure you know that the person logging on is the true user. Explain password policy and hand the new user a written copy to sign.

Run crack, or a similar program, on the password file to look for weak passwords. Inform those users immediately, but tactfully. Do not let other users use the password checking program. Obtain written management permission before running crack or any similar tool.

Check for inconsistencies in the password files.

Ensure that the password rules are being obeyed.

Users

Do not allow users to share a user id or UID

Run a regular check on user accounts and scan for the following.
- New suid/sgid programs.
- Change of IFS.
- Setting of umask away from default.
- World or group writable files.
- Suspicious programs that could be security risks such as password crackers, ethernet sniffers, etc.
- Processes listening to the higher numbered ports.

Run the “last” command and check for inconsistencies in login behavior.

Examine /var/adm/sulog. Check for unusual patterns. Delete file when it becomes bigger than one page.

Files

Examine the report files generated by ASET.

Ensure that the system backups are run regularly.

7.1.2. Configuring Windows systems (Windows 2000)[4]

7.1.2.1. Introduction

This is a brief guide intended to help you understand the basic steps necessary to safely install a new copy of Windows 2000. The information in this guide applies to:

Microsoft Windows 2000 Advanced Server
Microsoft Windows 2000 Professional
Microsoft Windows 2000 Server

Note to the reader: this is an adapted version of the guide available at Microsoft’s website. The guide has been adjusted to fit the conditions present at the company. Specifically, steps 4-6 have been excluded as these are irrelevant for configuring the system.

7.1.2.2. Step 1: Performing a base installation

During the installation process, a system will be vulnerable to exploits of known vulnerabilities until the installation has completed and all applicable service packs and hot fixes have been applied. To prevent a system being compromised during the setup process, disconnect the system from all networks if possible. If network connectivity is required for the setup process, ensure the network has not been compromised by security attacks, is not reachable from the public Internet, and is not reachable by systems infected with worms or viruses.

Choose one of these two installation methods, listed in order of preference:

Install Windows 2000 while not connected to a network. Typically this is done by using a CD. It is recommended to integrate the service pack to create a Windows 2000 Service Pack 3 installation CD. Follow the Service Pack Installation Guide[5] to create an integrated installation and burn the installation share to a CD.

Ensure all current roll-up packages and hotfixes are available for install while disconnected from the network. Follow the Hotfix Installation and Deployment Guide[6] for detailed information about how to install hotfixes. The base install of Windows 2000 is vulnerable to security attacks and should remain disabled or disconnected from the network until all current service packs and patches are applied.

Install Windows 2000 while connected to a network that has not been compromised and is not reachable from the public Internet. An integrated Service Pack installation share is recommended for this method.

The base configuration of Internet Information Server (IIS) includes many of the most widely exploited vulnerabilities. To limit the risk of compromise, install Windows 2000 using a unattend.txt file with entries to disable IIS. For more information about how to use a unattend.txt file while installing Windows 2000, read Chapter 13[7] of the Deployment Planning Guide. An integrated Service Pack installation share is recommended for this method.

7.1.2.3. Step 2: Securing the base installation

Now that the operating system is up and running, it is time to make it more secure. Depending on how your initial setup was completed in Step 1, you might be able to skip some of the following steps.

Install the latest Windows 2000 Service Pack. Follow the Service Pack Installation and Deployment Guide for detailed information about how to install the Service Pack.

Install updates released since the latest service pack. Follow the Hotfix Installation and Deployment Guide for detailed information about how to install hotfixes. Remember: you should not connect it to the network until this step is complete.

Install the latest version of Internet Explorer, as well as all service packs and critical updates. This step is necessary even on servers, because administrators often use the server’s browser while working on the system.

7.1.2.4. Step 3: Securing the system

To continue securing your system, you must follow the Microsoft Windows 2000 Professional Security Checklist[8].

Verify that all disk partitions are formatted with NTFS;
Verify that the Administrator account has a strong password;
Disable unnecessary services;
Disable or delete unnecessary accounts;
Protect files and directories;
Make sure the Guest account is disabled;
Protect the registration from anonymous access;
Apply appropriate registry ACLs;
Restrict access to public Local Security Authority (LSA) information;
Set stronger password policies;
Set account lockout policy;
Configure the Administrator account;
Revoke the Debug programs user right;
Remove all unnecessary file shares;
Set appropriate ACLs on all necessary file shares;
Enable security event auditing;
Set log on warning message;
Install anti-virus software and updates;
Install service packs and critical patches;
Automate patch deployment;
Scan system with the Baseline Security Analyzer;
Additional security settings;
Install the latest Service Pack;
Install the appropriate post-Service Pack security hotfixes.

7.1.3. Applying security updates

Prior to their implementation, newly released security updates (or patches) are subjected to a risk analysis to determine the necessity, the impact, and timing of applying the update. In case the patch is considered necessary, testing will follow[9] before actual implementation. Updating of Windows 2000 systems is automatically performed through Tivoli Management Framework[10] (TMF). UNIX systems, however, need to be updated and patched manually.

7.2. Procedure flow charts

7.2.1. Configuring Windows and UNIX systems

TBD

7.2.2. Applying security patches (Windows)

TBD

7.2.3. Applying security patches (UNIX)

TBD

8. REFERENCES

[1] Adapted from [BRE98].

[2] Runs a series of tests on passwords as they are entered by the user and refuses passwords that fail the tests. It is designed to work with shadow password systems.

[3] Crack is a password guessing program that is designed to quickly locate insecurities in UNIX (or other) password files by scanning the contents of a password file looking for weak login passwords. It can be configured to run with shadow passwords.

[4] Adapted from http://www.microsoft.com/technet/security/tools/w2knew.mspx

[5] http://www.microsoft.com/windows2000/downloads/servicepacks/sp3/spdeploy.htm

[6] http://www.microsoft.com/windows2000/downloads/servicepacks/sp3/hfdeploy.htm

[7] http://www.microsoft.com/windows2000/techinfo/reskit/dpg/Chapt-13.DOC

[8] See http://www.microsoft.com/technet/security/chklist/w2ksvrcl.mspx for more details.

[9] The testing scheme must address the basic and representative functionalities of the system tested.

[10] See http://www-306.ibm.com/software/tivoli/products/mgt-framework/

9. APPENDIX A: GENERIC BACK-OUT PLAN

Inform users on system malfunctioning
Get Operating Systems on-line
Restore latest system backup from tape
Perform testing to ensure the system is fully operational
Inform users on system status

Information Technology Manage Factory 管理廠房資訊科技系統

Windows and UNIX Security Configuration and Patch Update Procedure
Home / 2. IT Security (資訊保安) / Windows and UNIX Security Configuration and Patch Update Procedure