CIW Security 1D0-470: Operating System Security: Text-only Version

CIW Security 1D0-470: Operating System Security


Lesson 1. Course Introduction

This course covers network security issues that arise at the operating system level. It begins with a discussion of security principles and standards that have been adopted by the industry.
You then learn about the major areas of vulnerability of popular operating systems such as Windows 2000 and Linux.
Finally, you learn how to configure operating systems for increased security. You learn how to activate built-in security features, how to configure password parameters for improved authentication, and how to set permissions on files, folders, and shares.

Lesson 2. Security Principles

The International Organization for Standardization (ISO) has worked to develop security concepts and standards that can be applied worldwide.
After completing this lesson, you should be able to:

The chief motivation for connecting systems to the Internet is to share information and resources. However, this connectivity also makes systems and data vulnerable to unwanted activity.
Because Linux and Windows 2000 have been so widely used as Internet and intranet servers, they have become targets of uninvited attention. Corporate intranets and the Internet bring the potential for uninvited visitors, who can access the same data and applications, perhaps causing damage.


Note: Although this course focuses on Linux, most of the security principles you will learn apply to other UNIX flavors as well, including Solaris, AIX, HP-UX, and FreeBSD.


In any organization, solid and coherent thinking is needed  in order to develop a strong security policy. Such a policy should explain what measures to deploy if an attack is recognized so that uninvited access can be countered, and data and applications can be protected.
Most successful policies are based on a few basic security principles.

*Definition of Security
Before examining the details of security, we need to establish a working definition of what the term means in this context. We will begin with definitions from the International Organization for Standardization (ISO).
ISO 7498-2 defines security as a means to reduce, to the greatest extent possible, the vulnerability of data and resources (this usually means computer/network data and applications).
An asset is another term for the data, applications, and resources that exist on any computing system. The vulnerabilities described by ISO can be anything that allows someone to gain access to these assets. Usually, a vulnerability is some kind of weakness in the system, an overlooked aspect of the entire system setup and processes. A threat is any action that compromises the system's safety.

The ISO 7498-2 document defines certain security services for all levels of local and remote system and application access. These services are also described in the Open Systems Interconnection (OSI) reference model.
The definitions are summarized below.
Examine the following table
Service Purpose
Authentication The means by which one can prove or identify oneself. For example, a user account login with a password.
Access control Determines what system resources a user or service may use, view, or change. After a user has been authenticated, the access control service on an operating system determines where that authenticated user can go.
Data confidentiality Protects data from unauthorized disclosure. For example, remote users may use some form of encryption so eavesdroppers cannot "see" their work.
Data integrity Protects against active threats (such as altering data) by verifying or maintaining the consistency of information.
Non-repudiation When two systems interact, if one later denies that the set of transactions occurred, it is attempting repudiation. The other party may then try to prove that the transaction actually did occur. Nonrepudiation is the security service that provides such proof.










In this lesson, you began learning about the security concepts and standards developed by the International Organization for Standardization (ISO).
You learned how the ISO defines security, and the five basic security services defined in ISO 7498-2.

Lesson 3. Evaluation Criteria

A variety of security standards are used in different regions and industries.
After completing this lesson, you should be able to:

Many governments and organizations will not do business with others who have not proved security compliance with a third-party standard.
Security is often a regional concern, meaning that various industries, organizations, and national governments have different procedures and standards bodies that provide effective security models. More recent efforts have attempted to create a global ISO security document.
The criteria documents discussed in this lesson are not specific to Linux or Windows 2000. They are meant to provide a framework for various network types.

*ITSEC Document BS 7799
The European Information Technology Security Evaluation Criteria (ITSEC) document BS 7799 outlines network threats in Europe, along with various "controls" you can implement to reduce the likelihood of a crippling attack.
BS 7799 defines vulnerability as something for which the systems administrator is responsible. It characterizes a threat as something over which you have little control.

BS 7799 was rewritten in 1999. It details the following types of procedures you can implement to secure your systems:


Additional concerns include e-commerce, legal issues, and reporting methods.
For more information on ITSEC, visit www.cesg.gov.uk/assurance/iacs/itsec/index.htm.

*Trusted Computer Systems Evaluation Criteria (TCSEC)
In the United States, the National Computer Security Center (NCSC) is responsible for establishing the security criteria for trusted computer products.
The NCSC understood that just one compromised system can become a platform used to defeat the security of all other computers on the network.
To this end, they created the Trusted Computer Systems Evaluation Criteria (TCSEC), Department of Defense (DOD) Standard 5200.28. The primary purpose behind TCSEC is to ensure that all systems on a network are secure.

TCSEC designates several security ratings, ranging from Level A to Level D. Level D indicates a non-secure system. Level A is the highest rating, and is used on military computers.
Levels A, B, and C have numeric sublevels. For example, Level A has A1; Level B has B1, B2, and B3; and, Level C has C1 and C2. The lower the number, the higher the security, as shown in the table below.
Examine the following table
Level Description
D No inherent security. A classic example is an MS-DOS system.
C1 Discretionary security protection. The system need not differentiate between users. It can provide rudimentary access control. An example might be a small departmental desktop publishing system, with files for common use and an area for individual use.
C2 Discretionary access security. The system differentiates between users, but treats them uniquely. System-level protection exists for resources, data, files, and processes. Certain implementations of Windows 2000 and Linux can be made C2-compliant.
B1 Labeled security protection. The system provides more protection, such as varied security levels. Also, mandatory access controls beyond those levels place resources in compartments, isolating users in cells, and thus offering further protection. Examples are AT&T System V UNIX with MLS, and IBM MVS/ESA.
B2 Structured protection. This level supports hardware protection. Memory areas are virtually segmented and rigidly protected. Examples are Trusted XENIX and Honeywell MULTICS.
B3 Security domains. This level offers data hiding and layering, preventing all interaction between layers. An example is Honeywell Federal Systems XTS-200.
A1 Verified design. This level requires rigorous mathematical proof that the system cannot be compromised, and provides all the features listed in lower levels. An example is Honeywell SCOMP.


TCSEC Level C is often implemented in commercial environments. It requires that owners of data be capable of determining who can access the data, a privilege called discretionary access control (DAC):


TCSEC is similar to ITSEC. However, ITSEC rates functionality (F) and effectiveness (E) separately.
The TCSEC Level C2 is equivalent to the ITSEC Level F-C2, E2.

*Levels C2 and F-C2, E2
The key requirements for TCSEC Level C2 and ITSEC Level F-C2, E2 are that a system have certain aspects of discretionary access control, object reuse, auditing, identification, and authentication:


You can obtain a copy of the "Network Rating Model," which defines the TCSEC evaluation process in complete detail, at www.radium.ncsc.mil.

*Common Criteria (CC)
The Common Criteria (CC) is a standard that unifies the various regional and national security criteria, such as the ITSEC and TCSEC, into one document standardized by ISO.
The Common Criteria is currently ISO International Standard (IS) 15408.

The CC specifies and evaluates the security features of computer products and systems. It is the first internationally accepted standard for IT security. It is based on the ITSEC and TCSEC documents, and is intended to replace them as a worldwide standard.
The CC provides two basic functions:


*Key Concepts
Three concepts are essential to understanding the CC. The concepts are largely used for communication and process purposes in determining the correct security product and system for a given situation.
Examine the following table
Concept Definition
Protection Profile (PP) A document created by IT administrators, users, product developers, and other parties that defines a specific set of security needs. It communicates the needs to the manufacturer.
Security Target (ST) A statement from the manufacturer that claims what security an IT product or system can provide. It contains product-specific information that explains how the particular product or system meets the needs of the PP.
Target of Evaluation (TOE) The IT product or system to be evaluated. It must be evaluated using the specific security requirements listed in the PP and the ST documents. To comply with the CC, the product must be analyzed and tested by an accredited third party.


You can download the latest CC standard at the Computer Security Resource Clearinghouse at http://csrc.nist.gov/cc, or visit the ISO at www.iso.ch.









Topic 3.1 Exercises


* Exercise 1
Try researching security criteria and products.


Examine the following table
Step Action
1 Visit the ITSEC homepage at: www.cesg.gov.uk/assurance/iacs/itsec/index.htm.
2 Navigate to the page on security evaluation criteria and read the general descriptions of the ITSEC, TCSEC, and Common Criteria standards.
3 Search their products database, and produce a list of networking products with E2 level ITSEC classification.
4 Download the formal document defining ITSEC criteria and review the definitions of ITSEC security levels.
5 Visit the Common Criteria Project Web site at: csrc.nist.gov/cc/.
6 Download the latest version of the Common Criteria. Read the first section, which introduces you to the general model.
7 Follow links to pages about specific products that have been tested. List at least five that have passed the Common Criteria evaluation process.


In this lesson, you learned about some of the variety of security standards being developed and used in different regions and industries.
You learned about the ITSEC standard developed in Europe, and the TCSEC standard used in the U.S.
You also learned about the effort to establish a unified security standard under the Common Criteria.

Lesson 4. Security Levels and Mechanisms

Security level classifications are used to indicate how much security is needed at different parts of your system. Security mechanisms can then be applied appropriately.
After completing this lesson, you should be able to:

Linux and Windows 2000 systems provide a wide range of security options. They allow you to tailor the security on every system to the needs of that particular implementation.
There are numerous ways to secure both Linux and Windows 2000 systems. We will examine not just the "what" but also the "why" and "when" so you can evaluate your company's need to implement a given security measure.

Although you can make very granular decisions about security on a case-by-case basis, there are three conventional broad classifications of security levels that you can also use.
Those levels are low, medium, and high.
The use of these arbitrary designations allows administrators to group the types of countermeasures and protections for ease of application.

These security level designations are arbitrary, and can be tailored to suit your environment. There are some general guidelines, however, as summarized in the table below.
Examine the following table
Level Applicability Implementation
Low Computer is in a secure location.
Computer does not contain or access sensitive information.		 No operating system security is applied.
Virus software is used.
Computer is secured against theft.
Medium Computer holds or accesses corporate data.
Computer is accessible to more than one individual.
Accidental information-damage protection is needed.		 Auditing is enabled.
File permissions are used.
Account policies are implemented.
Countermeasures and protections are enabled in the operating system.
High Computer holds or accesses highly sensitive or very valuable information.
Computer is in a high-risk location.		 The operating system is stripped down to the bare minimum needed for chosen functions.
Additional strict countermeasures and protections are enabled in the operating system.


*Security Mechanisms
Security mechanisms are used to implement security systems. Two forms of mechanism exist: specific and wide.

*Specific Security Mechanisms
Specific mechanisms are those that can be implemented at different levels (or layers) to provide security. They include the following technologies:

*Wide Security Mechanisms
Wide mechanisms are not limited to any specific layers or levels. They include:


*Security Management
To help managers develop an approach and a policy, different areas of security management should be identified. These areas are:












Topic 4.1 Exercises


* Exercise 1
Try researching the security management process at your company.

Examine the following table
Step Action
1 Examine the process of security management used at your company. List the security activities that each person performs and try to place each activity into one of the three basic areas of security management:
  • System security management
  • Security service management
  • Security mechanism management
2 Identify which security mechanisms are currently being used, and determine how they are administered.


In this lesson, you learned about the security level classifications often used to indicate how much security is needed at different parts of a network.
You also learned about the security mechanisms used to protect a system. You learned which ones are considered "wide" mechanisms that can be applied at varying layers of a system, and which are "specific" mechanisms used at specific layers.

Lesson 5. Windows 2000 Security

Security problems can arise with all operating systems, including Windows 2000.
After completing this lesson, you should be able to:

Microsoft Windows 2000 has been specifically designed to meet industry and government security needs. But security problems with Windows 2000 continue to occur.
The popular site www.antionline.com lists well-known security exploits for compromising Windows 2000. Every week, new problems seem to arise.

Let's look at some of the specific Internet-related exploits currently practiced, and how and where these attacks occur on Windows 2000.
This knowledge will enable you to secure against the current problems, and implement a system configured to minimize the possibility that new attacks will be successful.

Before you can understand how to fix Windows 2000, you first need some knowledge of its problems. Default installations of almost any operating system are not configured for optimal security. Operating systems default to low security settings for two main reasons:


The key vulnerabilities in any operating system are in the following areas:
Windows 2000 has an additional area of vulnerability — the Registry. The Windows 2000 Registry must be secured.

When installed using the default settings, Windows 2000 has many vulnerabilities.
For example, it creates an administrator account by default during the installation process. Hackers might use a program such as RedButton to reveal the default account name and some of the additional information they will need to access your account.

With RedButton, the user simply enters the target computer's IP address, and clicks OK.

RedButton provides two important pieces of information — the name of the built-in administrator account (even if it has been renamed), and a list of all share points (including hidden ones).
It is possible to log on to the C$ default share, even if the administrator has not explicitly shared any directories on the system.

After using RedButton to find the administrator account name and share point, all a hacker needs is the account password.
A hacker might use any of a variety of password-cracking programs to attempt to reveal your password.

*Windows 2000 Settings
Let's take a closer look at some of the default Windows 2000 settings that make attacks like this one possible.

Begin by opening the Properties dialog box for the C: drive. Choose the Security tab, and then click the Advanced button.

Note that the Everyone group has full control of the root.

Now open the Local Security Settings snap-in from the Administrative Tools menu.

Expand the Security Settings | Account Policies | Password Policy icon.
Note that except for a default maximum password age setting, no additional password history, aging, or length settings are configured by default.

Select the Security Settings | Local Policies | Account Lockout Policy icon.
Note that no account lockout policies have been enabled.

Expand the Security Settings | Local Policies | Audit Policy icon.
Note that auditing is not enabled either.

You can activate password and auditing settings by double-clicking each and changing the appropriate settings.
For the moment, though, let's focus on another default setting.
It's important to understand that Windows 2000 Server includes the Server Service turned on by default. This setting is not optimal for a Windows 2000 Internet server. Deactivating it can be an effective way to increase your server's security if it is acting as a Web server.

You can solve this problem by disabling the default administrative share.
Right-click the C: drive and select Sharing.

Select the Do not share this folder option, and click Apply.

You have just disabled the default hidden share for your system. Disabling this share is important if you need to keep the Server service running — for example, if you're using Distributed File System (DFS) to share drives for your Web server.









In this lesson, you learned about the security vulnerabilities of operating systems in general, and specific vulnerabilities that apply to Windows 2000.
You learned about the default security settings of Windows 2000. You also learned how hackers might use the default hidden share and password cracking software to gain illicit access to a system.

Lesson 6. Windows 2000 Security Architecture

Windows 2000 has built-in support for basic security features, including auditing, encryption, access control, and user authentication.
After completing this lesson, you should be able to:

You use the Windows 2000 Security architecture whenever you add, modify, or delete a user, or whenever you modify the Registry.
It is important to understand what subsystems and files you are manipulating as you modify services and security settings in Windows 2000.

*Windows 2000 Security Components
The Windows 2000 and Linux operating systems have built-in support for auditing, administration, encryption, access control, and user authentication.
Specifically, Windows 2000 seeks to prevent the circumvention of security parameters through the five security components listed here.
These are the five Windows 2000 security components that apply to Level C2 certification under the TCSEC criteria.

*Discretionary Access Control
Windows 2000 supports discretionary access control as defined in the C2 requirements. Those requirements include allowing an object's owner to control who can access the object and how that access occurs.

*Object Reuse
Windows 2000 specifically prevents all system applications from accessing information contained in any resource (such as memory or disk) that another application has used.

*Mandatory Logon
Unlike in Windows for Workgroups, Windows 95, and Windows 98, all Windows 2000 users must log on to authenticate themselves before they can have access to any of its resources.
The lack of this necessary enforcement for network connectivity is another primary reason that networking had to be disabled for earlier Windows products to achieve a C2 rating.

*Auditing
Because Windows 2000 uses a single mechanism to control access to everything, that mechanism can also centrally record all accesses.

*Control of Access to Objects
Windows 2000 disallows direct access to any resource in the system. Before access is granted, the rights of the user or application to access that resource are first verified.
Windows 2000 can also invoke encryption as an access control strategy.

*Windows 2000 Objects
Windows 2000 is designed to handle all resources of any type in the system as specific objects. These objects contain the resource itself and the mechanisms and programs necessary to access it.
By encapsulating everything as objects and creating a single mechanism to use them, Microsoft created a single avenue for controlling access to those objects.
Because of this fundamental methodology, Windows 2000 is commonly called an object-based operating system.

Microsoft security is based on the following object principles:


The primary object types in Windows 2000 are:
The key goal of this architecture is consistency. The design, which requires all access to be authorized in the same way, diminishes the chances that the security mechanism can be bypassed.

*Security Subsystem
The local Windows 2000 security subsystem consists of the five key elements listed here.
These elements control user actions.

*Security Identifiers
Security Identifiers (SIDs) are statistically unique numbers assigned to all users, groups, and computers. "Statistically unique" means that the likelihood of two numbers being duplicated is extremely remote.
Every time a new user or group is created, it receives a unique SID. Each time Windows 2000 is installed and set up, a new SID is assigned to that computer. The SID uniquely identifies the user, group, or machine, not just on that particular computer but also during interaction with other computers.

To ensure that SIDs are unique, they are created with a formula that combines the computer name, current time, and the amount of time the current user mode thread has spent using CPU time.
An SID looks like this:
S-1-5-21-1649288664-1549824960-1244863647-500
SIDs are a cornerstone of the Windows 2000 security infrastructure, so we will use and discuss different aspects of them throughout this course.

*Access Tokens
Part of the key purpose of the logon process is to give all users access tokens after being validated. The access token consists of the user's SID, name, and the names and SIDs for any groups to which he belongs.
The access token is the user's "ticket" to access system resources. When the user attempts to access something, the access token is presented to Windows 2000. The system checks it against the object's access control list. If the user is authorized to use the object, access is granted.
Access tokens are issued only during the logon process, so any changes to the user's access rights require the user to log off and then log back on to receive an updated access token.

*Security Descriptors
Every object within Windows 2000 has a security descriptor as part of its properties. The security descriptor holds that object's security settings. It consists of the object owner's SID, a group SID for use by the POSIX subsystem, a discretionary access control list, and a system access control list.

*Access Control Lists
There are two types of access control lists — discretionary and system.
A discretionary access control list holds a list of users and groups and their appropriate permissions (either allowed or denied). Each user or group with specific permissions is listed in the discretionary access control list.
The system access control list contains a list of events that are audited for the object.

When the type of access control list is not specified, it is usually a discretionary access control list.
In this course, we will assume this is the case for any mention of access control lists.

*Access Control Entries
An access control entry (ACE) exists for each permission assigned to an object. Each ACE contains the user's or group's SID and permission to the object.
Access control entries are one of two types: AccessAllowed or AccessDenied. AccessDenied ACEs precede AccessAllowed ACEs in the ACL.
When authorization for a user is being checked, the process stops as soon as an appropriate AccessDenied ACE or the end of the ACL is reached, whichever comes first. Therefore, No Access takes precedence over all other permissions.

*Security Subsystem Software
Now that you understand the basic elements of the security subsystem, we will discuss the actual software within Windows 2000 that allows these elements to work.

The security subsystem consists of several parts, shown here.
The Winlogon, Local Security Authority, and the Netlogon service can be seen as processes in the task manager. The other pieces all consist of DLLs that are called and loaded by those processes.

*Local Security Authority
The Local Security Authority is a protected subsystem that is responsible for several tasks:

The Local Security Authority is also responsible for the following:


*Security Support Providers
The Microsoft Security Support Provider Interface is very similar to the Generic Security Services API as defined in RFC 2743 and RFC 2744. The Security Support Provider API provides a way for applications and services to request secure authenticated connections.

Security Support Providers are installable drivers that support any additional security mechanisms. At least three are included with the default installation of Windows 2000:

*Authentication Packages
The Authentication Package is the component that provides the actual user authentication. It verifies the credentials supplied through GINA.
When a user's credentials are verified, the Authentication Package returns the SIDs to the LSA so they can be included in the user's Access Token.

*Netlogon
The Netlogon service establishes a secure channel for pass-through authentication. To do so, it locates a domain controller with which to establish the secure channel.
It passes the user's credentials through the secure channel, then retrieves the domain controller's response in the form of the user's SIDs and user rights.

*Security Account Manager
The Security Account Manager is the actual database that holds the users and their credentials. It is stored in a portion of the Windows 2000 registry itself.
Each domain has a different SAM, which is part of the replication that takes place between domain controllers.













In this lesson, you learned about the basic security support features built into Windows 2000.
You learned about the five security components used to meet Level C2 certification under the TCSEC criteria.
You also learned about the five key components of the security subsystem.
Finally, you learned about the actual software components that underlie the security subsystem and how they perform basic security functions.

Lesson 7. Linux Security

Depending on their configuration and purpose, Linux systems can be susceptible to the same security vulnerabilities as Windows systems.
After completing this lesson, you should be able to:

In Linux, the equivalent of the Windows 2000 security architecture (i.e., the Windows 2000 Registry, GINA and the SAM) is a combination of text files and applications running in memory.
Some of these text files include the /etc/passwd, /etc/shadow, and /etc/groups files. Additional files include the Pluggable Authentication Module (PAM) configuration files.

Depending on their configuration and purpose, Linux systems are generally susceptible to the same vulnerabilities as Windows systems.
The problems listed here are especially important to understand when configuring Linux systems.

*Misconfigured Authentication Settings
Many times, user accounts are allowed to exist on systems, even after the user has stopped using them.
Accounts that are no longer used for legitimate purposes can still be used to gain illicit access to your system.

*Unnecessary Services
Consider the purpose of your system. The general rule for establishing a secure server is to dedicate each server to only one purpose.
For example, if you want to configure an FTP server, you should lock down all other daemons. If, for example, you are reasonably sure that you will not need to access your Linux server remotely, you can disable Telnet access.

*Default Account Policies
Although Linux systems audit by default, you should consider reviewing and defining user account policies.

*Access to Sensitive Commands
By default, many Linux distributions allow non-root users to use the halt, reboot, and poweroff commands. It is good practice to limit access to these commands only to the root user.

*System Bugs
As with any operating system, Linux daemons and applications often contain bugs that lead to a security breach.





Topic 7.1 Exercises


* Exercise 1
Try researching common Linux security vulnerabilities.

Examine the following table
Step Action
1 Use your favorite search engine to locate the latest information on known Linux security vulnerabilities.
2 Identify at least five of the most common security bugs.
3 For each item on your list, research steps that are taken to reduce the risk or plug the security hole.


In this lesson, you learned about security problems that can affect the Linux operating system. You learned about five common problems that can arise in Linux systems.

Lesson 8. Pluggable Authentication Modules

Pluggable Authentication Modules can be used to strengthen authentication on Linux servers.
After completing this lesson, you should be able to:

Pluggable Authentication Modules (PAMs), allow developers and systems administrators to create additional authentication parameters without affecting existing authentication systems.

*Editing PAM Files
There's no centralized program to modify Linux PAM files and applications. You must configure PAMs using their configuration files, which reside in both the /etc/pam.d/ and /etc/security/ directories.
The following table shows the relevant PAM directories and their purposes.
Examine the following table
PAM Directory Description
/etc/pam.d/ Contains the files that allow you to determine what must occur before a user can be logged in
/etc/security/ Contains files that allow you to set limits concerning users and daemons when they have logged onto the system
/lib/security/ The actual location of the PAM modules


*PAM Entry Format
To use PAM authentication services, you add one or more lines of code to the /etc/pam.d/login file that runs when a user attempts to log in.
The syntax is shown below.
  moduletype   flags   path   [args]  

Begin by specifying the module type. There are four types of PAM modules, and they perform the services described in the table below.
  moduletype   flags   path   [args]  
Examine the following table
Module Type Description
Auth Specifies ways in which the user will authenticate with the system (usually via a password)
Password Allows the system to update a user's account information (username and password)
Account Controls how the user will access the system. Allows you to control when a user can access the system and which resources she can access. Also allows you to choose specific locations and terminals from which a user can authenticate.
Session Invokes checks on applications and services that a user invokes after authentication


Flag types determine module priority. The four types are listed below.
  moduletype   flags   path   [args]  


Note: The order of entries in the /etc/pam.d/login file is important. Imagine what would happen if a system read a module flagged sufficient before reading all other modules.


After specifying a module type and a flag, you can specify the path of the actual PAM module. Specific arguments can follow but are not absolutely necessary.
  moduletype   flags   path   [args]  

The following three lines are taken from a typical /etc/pam.d/login file.
  auth  required  /lib/security/pamsecuretty.so
  auth  required  /lib/security/pampwdb.so shadow nullok  
  auth  required  /lib/security/pamnologin.so
The first line requires that the system check the /etc/securetty file to restrict direct root login from a remote system.
The part of the line that reads /lib/security/pamsecuretty.so is the path to the actual module.

Note that the second line has two arguments, shadow and nullok. These arguments tell the operating system to use its own password database, and check for the presence of the shadow passwords package.
  auth   required   /lib/security/pamsecuretty.so
  auth   required   /lib/security/pampwdb.so shadow nullok  
  auth   required   /lib/security/pamnologin.so
With PAM, arguments are often not necessary. When used, they customize PAM behavior.

The third line requires that the system load the /lib/security/pamnologin.so module, which checks for the presence of the /etc/nologin file.
If /etc/nologin is present, the system will deny login to all accounts except the root.
  auth   required   /lib/security/pamsecuretty.so
  auth   required   /lib/security/pampwdb.so shadow nullok  
  auth   required   /lib/security/pamnologin.so

*The /etc/security Directory
The following table shows the purpose of each file in the /etc/security/ directory. The third column describes the entry that must be entered into the /etc/pam.d/login file for the module to be properly configured.
Examine the following table
File Description Entry
access.conf Determines which users can access the machine and from where account required /lib/security/pamaccess.so
group.conf Controls login at a group level account required /lib/security/pamgroup.so
time.conf Sets times when specific accounts can log on account required /lib/security/pamtime.so
limits.conf Specifies limits based upon percentage of processor usage and number of processes a user can run simultaneously session required /lib/security/pamlimits.so
console.apps A directory that contains text files that allow you to configure who can use an application You can specify users as well as entries.


*Telnet and the Root Account
The /etc/securetty directory disallows direct access to a terminal via Telnet. Any terminal definition (such as tty1 or tty2) that is present in this file will not allow direct root logon.

*Instantly Denying Telnet Logon
By using the /etc/nologin file, you can deny Telnet access to all local and remote users. The mere presence of the file will deny logon to all users except root.
By default, Linux systems do not allow direct logon using the root account; therefore the only way to log on to a system with the /etc/nologin file is to log on interactively as root. This file is useful during an emergency or for systems that require only interactive root logon.
You can populate the nologin file with any text you choose. Its contents will be displayed upon login failure.

Note: The /etc/nologin file will have no effect on FTP and HTTP sessions. Similarly, the /etc/nologin file does not support authentication via Secure Shell.












Topic 8.1 Exercises


* Exercise 1
Try configuring the /etc/pam.d/login file to use common PAM services.

Examine the following table
Step Action
1 Please Note: For the exercises in this course, you should set up an isolated network for practice. Do not use your production network for these practice exercises.
Open the /etc/pam.d/login file.
2 Examine the file and determine if any PAM services are currently being used. PAM entries will begin with one of the four module types: auth, password, account, or session.
3 Add an entry to restrict direct root login from remote systems.
4 Add an entry to check for the presence of the shadow passwords database.
5 Add an entry to specify which users can log on.
6 Add an entry to set times when specific accounts can log on.
7 After saving the file, check as many of your new settings as you can. Try logging on as an unauthorized user, at the wrong time, or to the root from a remote system. Verify that your new login restrictions are working.


In this lesson, you learned to use Pluggable Authentication modules (PAMs) to strengthen authentication on your Linux servers.
You learned about the directory and file structure used for PAM files. You learned about the four module types available with PAM and the four flags used to determine module priority.
Finally, you learned to add entries to the login file to activate a variety of PAM services, including restricting user access, group access, direct root login, and checking for the presence of the shadow passwords package.

Lesson 9. Passwords

Passwords are one of the most basic security measures. If a password becomes compromised, the basic security scheme may be undermined.
After completing this lesson, you should be able to:

Improperly secured user accounts are a primary avenue attackers use to enter systems.
Many potential problems can be prevented by careful user account management, including good password selection, effective policies enforcing sound user habits, and the proper assignment of permissions. All these requirements must be met to achieve a measure of security.
Complicating the whole process is the fact that all these tasks must be completed with minimal intrusion and inconvenience to users.

Passwords are one of the core strengths of basic Linux and Windows 2000 security. If the password is compromised, the basic security scheme or model is affected.
To enforce good password selection, you need to do more than just select the appropriate values in account policies. You also need to help users choose strong passwords.

Because so many different operating systems exist, no universal standard exists for the ideal password.
However, strong passwords generally contain at least three of the following four types of content:

Strong passwords should also obey the following rules:


*Windows 2000 and Strong Passwords
A good password is one that cannot be easily guessed and is resistant to even brute-force attacks such as dictionary attacks. The best way to ensure that these characteristics are present is to require strong passwords.


Term: Dictionary Attack: An attack in which a hacker tries to guess user passwords by using words from a file containing various possible passwords.


Windows 2000 supports passwords of up to 127 characters. Windows NT has a limit of 14 characters, as do many Microsoft clients (e.g., Windows 9x).
Of course, it would be impossible to expect users to remember 127-character passwords. Even 14-character passwords would be extremely difficult to remember.
A practical, strong Windows 2000 password generally uses at least six characters, does not contain any part of the user's name, and uses at least three of the following four types of content mentioned previously:

Most password-cracking applications, such as L0phtCrack, can defeat seven and eight-character passwords as easily as they can a six-character password. For more information about password security, consult the following URL:
www.microsoft.com/NTServer/techresources/security/password.asp

When remote Windows systems older than Windows 2000 connect to your Windows 2000 system, they can use passwords up to 14-characters long. To be downward-compatible with previous Windows systems, Windows 2000 uses the same password hashes.
Therefore, cracking programs such as L0phtCrack, pwdump and John the Ripper work for Windows NT and 2000 networks.

*Enforcing Strong Passwords
You can enforce strong passwords by opening the Local Security Settings snap-in and configuring the Security Settings | Account Policies | Passwords must meet complexity requirements value.

Enabling this setting requires users to use passwords that are at least seven characters long and have at least one alphanumeric character.

*Linux and Strong Passwords
Red Hat Linux systems default to using six-character passwords.
By default, Linux systems also reject any password that resembles a "dictionary" password, which is any text string that appears too much like a name you would find in a standard dictionary. For example, it would require you to use a password such as bigmo$ney instead of bigmoney.
You can, however, enforce more stringent passwords. For example, many Linux systems administrators prefer a password of 8 characters, and require two non-alphanumeric characters.

*Shadow Passwords
Some years ago, the /etc/passwd file on all UNIX systems contained all username and password information. The /etc/passwd file was world-readable, because users needed to access this file to log on and/or change their passwords.
It was quickly discovered that including all this information was a problem. Using any password cracking application such as John the Ripper or L0phtCrack, hackers could obtain the passwords from this file.

The shadow password package removes the encrypted passwords from the /etc/passwd file and places them into the /etc/shadow file, which is readable and writeable only by root.
Users can still change their passwords, because the shadow package allows users to initiate a password change. The accompanying shadow package files (e.g., useradd, pwconv, and groupadd) can be run by any user, but are the only files that can write to the /etc/shadow file. This way, non-root users can update their passwords without having to involve the root user.

*Understanding the Root Account
The root account is not necessarily unique. A privileged user is simply any user who has the user identifier (UID) of 0. You can specify multiple privileged users, if you prefer.
Linux, like all UNIX systems, differentiates users with the UID assigned at account creation time. Numbering begins from 0, and in most UNIX systems (including Linux), the lowest number (or highest privilege) is assigned to the login account called root.
Root can execute any program, open any directory, examine any file, change the attributes of any object in the system, and perform many other functions with little or no restriction.











Topic 9.1 Exercises


* Exercise 1
Try enforcing strong password use in Windows 2000.

Examine the following table
Step Action
1 Please Note: For the exercises in this course, you should set up an isolated network for practice. Do not use your production network for these practice exercises.
Enable the password complexity requirement in the Local Security Policy snap-in of your Windows 2000 machine.
2 Shut down and restart Windows 2000.
3 Try changing the password on a user account. Verify that you are now forced to use a strong password.



* Exercise 2
Try strengthening default password settings in Linux.

Examine the following table
Step Action
1 Please Note: For the exercises in this course, you should set up an isolated network for practice. Do not use your production network for these practice exercises.
In X-Windows or at the terminal, open linuxconf.
2 In linuxconf, navigate to Users accounts | Policies | Password & account policies.
3 At the Policies tab, change the Minimum length value to 8, and the Minimum amount of non alpha char value to 2.
4 Select the Params tab. Change the Must change after # days value to 180, and the Warn # days before expiration value to 15.
5 Test your work by adding a new user and creating a password.


In this lesson, you learned how passwords are used in Windows and Linux systems.
You learned about the four basic elements of a strong password.
You also learned about the default password settings in Windows 2000 and Linux, and how to strengthen them.

Lesson 10. Verifying System State

To maintain a secure network, it's best to establish a baseline of normal activity and to continually monitor for irregularities.
After completing this lesson, you should be able to:

When examining the current state of the system, the first (and usually most difficult) task is to make sure that only the necessary accounts are used and that each account holder has the minimum permissions necessary to carry out his or her duties.
You should then take measures to learn more about your system. Find ways, for example, to scan the hard drive for writeable files, and determine a baseline of activity.
Try to determine the processes that normally run on your system. After establishing a baseline, you can then determine anomalous activity. Any time you can generate and review reports concerning the system's state, you can be more confident that it is secure.

Verifying the state of a server intended for a specific task is sometimes easier, because only the accounts necessary to use the server need to be installed.
If, as in most cases, the server is intended for general-purpose file and print duties, the majority of users need access. In large organizations, this requirement can make it extremely difficult to make sure no additional accounts exist. Just keeping up with disabling accounts for employees who have left the company can be daunting.

Various techniques exist to solve this problem. One of the primary concerns is to ensure that new accounts are not being added or permissions of existing accounts changed.
One of the easiest ways to cross-reference such information on non-domain controllers (i.e., stand-alone Windows 2000 systems) is by using the net user and net localgroup command lines redirected into a text file. By running these commands regularly and comparing their output to the existing list of accounts, you can easily detect problems.

Some built-in tools, such as the system task scheduler (available through the Control Panel), can automate the process. Other external tools, such as Perl or diff, can automate the comparison between the standard list and the current settings.

On Linux systems, make a copy of the /etc/passwd, /etc/shadow, and /etc/group files and keep them safe. You can then compare these files with more recently generated ones to ensure that no illicit users have been created.

*Managing Accounts in Windows 2000
Let's take a closer look at how to review and eliminate unnecessary accounts in Windows 2000.
Begin by making a record of your starting users.
Open a command prompt and change to the C:\ directory. Enter the command shown here to generate a text file with a list of user accounts.

You can then use Notepad to open C:\users.txt and review the complete list of users on the system.

Now use the net localgroup command to generate a text file with a list of group accounts.

After creating and reviewing your lists of users and groups, it's fairly easy to remove accounts you determine to be extraneous or unused.
Begin by opening the Active Directory Users and Computers snap-in.
Note the variety of users and groups listed in the Users folder.

Select one or more user or group objects you wish to delete.
In this case, we are removing Carlos Fernando's account as well as the DHCP Administrators security group.
After selecting the accounts, press the Delete button.

The user and group accounts you selected are now removed.



Topic 10.1 Exercises


* Exercise 1
Try reviewing and pruning user accounts in Windows 2000.

Examine the following table
Step Action
1 Please Note: For the exercises in this course, you should set up an isolated network for practice. Do not use your production network for these practice exercises.
On a Windows 2000 system, create three new user accounts and two group accounts.
2 Generate a text file with a list of users and a file with a list of group accounts.
3 Open the text files in Notepad. Identify one user account and one group account that you would like to delete.
4 Delete the two accounts you have identified.
5 Access the system task scheduler and arrange for user and group account lists to be generated every Monday morning at 8:00 a.m.


In this lesson, you learned the importance of reviewing the state of your system on an ongoing basis.
You learned to generate lists of users and groups for Windows 2000 systems, and to delete extraneous user and group accounts.

Lesson 11. Protecting Accounts

Protecting accounts from unauthorized access is a fundamental part of network security.
After completing this lesson, you should be able to:

One important step in protecting accounts is to rename the defaults.
These accounts include the Windows 2000 administrator and guest that are created automatically when software such as Internet Information Server is installed. The root account is an example of a default account in a Linux system.
These accounts absolutely must be protected because they are well-known by hackers.

*Windows 2000 Account Policies
In addition to keeping the user database clean, you need to help enforce good user habits and make it more difficult for attackers to perpetrate a brute-force attack on your accounts. These tasks are accomplished primarily through setting policies in Windows 2000.

Note: Policies are not just technical in nature. They should stem directly from a corporate security policy. Administrator activities should be governed by reliable policies as well. By deciding ahead of time exactly how you want activities to occur, you can lessen the possibility of security gaps.


After selecting the appropriate controls, you need to implement them. A good place to start is the password controls.
You can set account aging and lockout policies by modifying the values in the Account Policies | Password Policy and Account Policies | Account Lockout Policy sections of the Local Security Policy snap-in.

*Password Aging
Password aging is a security measure that sets time limits on how long a user may keep a certain password.
The following password aging sub-components are found in most operating systems:
Examine the following table
Feature Definition
Maximum password age The amount of time a user can keep an existing password before changing it.
Minimum password age The amount of time a user must keep a password before changing it.
Password history The number of passwords the operating system will remember. If a user chooses a password that resides in the user's password history database, the operating system will force the user to choose another password.
Minimum password length The lowest acceptable number of characters for a user password.
Password complexity Requires use of non-alphanumeric characters and/or uppercase letters. The resulting security gain is often small, since many users resort to techniques such as using password01, password02, etc., to get around it. While not optimal, this is an improvement over using the same password continuously.
Encryption options Red Hat Linux allows the use of md5 (theoretically non-recoverable) or 3DES passwords. Windows 2000 offers similar options.


Password age is an important feature to implement because it can make password cracking with brute force and dictionary attacks more difficult.
For setting the maximum password age, most organizations assign a value between 30 and 90 days. Requiring more frequent changes leads to user activities such as writing down passwords because they cannot remember them.


Note: A quick rule of thumb when deciding password aging elements is to compare the estimated security gain against the increase in difficulty to users. When the burden on users exceeds the additional security, you should consider very carefully whether the policy is too restrictive.


*Password Lockout
Password lockout is the primary tool used to thwart password guessing. It works by disabling accounts after a given number of invalid passwords have been entered.
This technique is especially useful for preventing remote brute-force or dictionary-based password attacks. A good number for lockout is three to five invalid logon attempts.


Note: Setting password lockout parameters is not the same as setting password aging parameters.


*Account Reset
You can also choose whether you want accounts to reset automatically after a given interval. This is often a wise option, because valid users can forget their passwords, especially near the times when password changes are required.
Large organizations, especially, must often allow accounts to reset automatically (be unlocked) after a given interval. Even a period as short as 15 minutes will generally prevent the effective use of a brute-force password attack.
Not using automatic account resetting may also open your network up to a possible denial-of-service attack. An attacker can disable users' accounts by launching a large password-guessing program against them.

*Setting Local Security Policy
To set local security policies in Windows 2000, begin by opening the Local Security Policy snap-in.

Navigate to Account Policies | Account Lockout Policy.
Select Account lockout threshold.

You can change the local policy setting to an appropriate value for your environment.
In this case, we will set the account to lockout after four invalid logon attempts.

Setting this parameter will usually thwart brute-force or dictionary-based password attacks, such as the one using NetBIOS Auditing Tool (NAT) illustrated here.





In this lesson, you learned about several common operating system features used to protect network accounts.
You learned about the four password aging features available in most operating systems.
You also learned about password lockout features and how the system can be configured to automatically reset accounts.
Finally, you learned to set account lockout policies in Windows 2000.

Lesson 12. Password Aging in Linux

A variety of password aging features are available in Linux systems.
After completing this lesson, you should be able to:

On Linux systems, password aging is managed by the chage command.
chage options are listed below.
Examine the following table
Option Meaning
-m The minimum number of days between password changes. A value of zero means the user may change a password at any time.
-M The maximum number of days between password changes.
-W The number of days before the user gets a warning message that her password will be rendered invalid.
-E The expiration date. After this date, the account will not be usable. Specified either as a number of days since UNIX epoch (January 1, 1970) or in MM/DD/YY form.
-d The day of the last change. The number of days since UNIX epoch (January 1, 1970) when the password was last changed. May also be specified in MM/DD/YY format.
-I (upper case i) If a password has been inactive for I days, the account will be disabled.
-l (lower case L) List current settings. Used by unprivileged users to determine when their passwords or accounts will expire.


Below is an example of using chage to learn current password aging settings for user James:
  host# chage –l james
  Minimum:        0
  Maximum:        99999
  Warning:        7
  Inactive:       -1
  Last Change:            Jan 13, 2002  
  Password Expires:       Never
  Password Inactive:      Never
  Account Expires:        Never

Suppose you wanted to set password aging parameters for James' account.
You wish to set an expiration date for the account, to require at least one day to pass between password changes, and require a change every 28 days. You also wish to give a warning three days before the required change.
The line of code to set these parameters is shown below.
  host# chage –m 1 –M 28 –W 3 –E 01/01/05 james  

Now suppose you wanted to force James to change his password immediately.
You can do so as follows.
  host# chage –d 0 james  
This command works by setting the last date of your password change to be day 0 (January 1, 1970). This date is sufficiently long ago that the user's password will definitely have expired, and thus must be changed. The next time James attempts to log on, he'll be prompted to change his password.

*Timing Out Users
To further enhance security, some organizations encourage the use of secure practices at the grassroots level.
You can install commercially available software that allows you to track and control the amount of time users spend on your system. Some packages allow you to automatically log off users when their login time expires.

A password-protected screen saver can also increase security. Users who leave their screens unattended or idle for too long may risk inviting someone to access confidential data or files on their workstations.
In such environments, a policy should be in place to automatically log off an idle screen or terminal. Screensavers are available for this, including xscreensaver and those that ship with desktop systems, such as Gnome and KDE.

*Monitoring Accounts
Security administrators must also constantly monitor user accounts for patterns of suspicious usage, such as users on vacation appearing to be active, or user accounts running up large, disproportionate computational bills and resources, such as memory and disk usage.
  host# last  
The wtmp file, as reported by the last command, contains specific account information, including:

You can use the last command to learn more about the contents of the wtmp file. You can also sometimes learn where the session originated (e.g., the Internet host address or gateway box).
The integration of this information into daily account monitoring can be very useful for detecting unusual patterns.

*System-Wide Event Logging Facility
In most Linux systems, the syslogd is a daemon process that listens to logging actions by several system and other daemons. It logs these requests into a central file or repository for analysis by pattern-hunting programs such as awk, grep, and sed.
The syslog facility has a configuration file called /etc/syslog.conf. This file contains levels of criticality such as info, warning, urgent, and critical. It also contains destinations to which requests should be sent, such as a file or a remote host.

*Additional Log File Locations
Below are some of the common locations of log files you should audit regularly on various UNIX systems:
Additional log files for various daemons, such as cron, Sendmail, and the print daemon exist in the /var/log/ directory.











In this lesson, you learned to use the password aging features available in the Linux operating system.
You learned to use the chage command to set various password aging parameters, including account expiration dates and password change intervals.
You also learned to use the last command to monitor account activities, and where to find the system log files that allow you to monitor network activities.

Lesson 13. Windows 2000 File Systems

The Windows 2000 file system uses a permissions feature to allow detailed control over file and folder access.
After completing this lesson, you should be able to:

Access control must be implemented in two places: locally and remotely.
Files can be accessed directly by users at the local console and remotely across the network.

*Windows 2000 File System
To use file permissions you must first implement the Windows 2000 file system (NTFS).
The alternative, File Allocation Table (FAT), does not support file permissions. FAT is appropriate only for extremely low security requirements.
Even NTFS cannot be counted on to completely protect files.

After the NTFS file system has been implemented, direct file security is implemented through Windows Explorer. Using Windows Explorer, you can set permissions on files and directories.
You need to understand what permissions you can assign, along with a few rules on how they are handled during daily activities.

*File and Folder Permissions
You can assign several permissions at the file and folder levels: read (R), write (W), execute (X), delete (D), modify permission (M), and take ownership (O).
These permissions grant the capabilities listed below.
Examine the following table
NTFS Permission On a Folder On a File
Read (R) Display folder name, attributes, owner, and permissions. Display file data, attributes, owner, and permissions.
Write (W) Add files and folders, change a folder's attributes, and display owner and permissions. Display owner and permissions; change file attributes; create data in and append data to a file.
Execute (X) Display folder attributes, make changes to folders within a folder, and display owner and permissions. Display file attributes, owner, and permissions. Run a file if it is executable.
Delete (D) Delete a folder. Delete a file.
Modify (M) Change a folder's permissions. Change a file's permissions.
Take Ownership (O) Take ownership of a folder. Take ownership of a file.



Additional attributes are also available. You can view them by selecting the Advanced button in the Security tab for any folder or file.

To simplify permissions management, Windows 2000 has several standard sets of permissions, listed below. Usually when permissions are assigned, these groups of permissions are used rather than individual permissions.
Examine the following table
Standard Folders Files
No Access None None
List Folder/ Read Data R, X Not applicable
Read R R
Read & Execute R, X R, X
Add W, X The ability to only add to a file
Add and Read R, W, X R, X
Change R, W, X, D R, W, X, D
Full Control All All


By assigning these permissions on a minimal basis, you can achieve the necessary access control. But determining what you need for minimal permissions can be difficult.
Recall that the Everyone group has full control of new NTFS partitions by default. This level is not acceptable, given that even unauthenticated users belong to the Everyone group.

However, if you indiscriminately remove the Everyone group from all areas or assign the "no access" permission to the Everyone group, you can cripple your Windows 2000 installation.
The Everyone group must have access to certain system directories (such as the logon directory) so users can connect and log on to the server. Users have not yet authenticated when they begin the logon process, so you must use the Everyone group to provide access.
Also, because "access denied" precedes and thus overrides "access granted," and because all users belong to the Everyone group, you will have completely disabled access to the file system if you assign "no access" to the Everyone group.

Directory (folder) permissions are assigned in the same way as files. Directory permissions affect new files created in the directory. Any newly created file starts with the same permissions as the directory.
Any time you set or change permissions on a directory, you can reset the permissions on any existing files in the affected directory.


Note: Windows 2000 strictly enforces inheritance with regard to NTFS. Inheritance means that all subdirectories and files have, or "inherit" the permissions of the parent folder. Thus, if you are working in a sub-folder and want to change permissions, you have to disable permissions inheritance for that folder.


*Drive Partitioning
Because the operating system directory permissions are so exacting, placing Windows 2000 on its own partition is a sensible choice.
Installing just Windows 2000 and no programs on this partition makes the administrative task much easier. A potential drive partitioning might resemble the one shown here.

Although this separate partitioning requires extra planning, it yields several appealing benefits.
Creating separate partitions ensures that if the data partition becomes full, the operating system and program files will remain largely unaffected, and the system will not crash. Also, the system data can be stored more easily, and inheritance is less of a concern.

*Copying and Moving Files
Finally, you should understand what happens when files are copied and moved from one location to another.
Whenever a file is copied to a new directory, the new file inherits the target directory's permissions.
When files are moved, the process is more complicated.

If a file is moved from one directory to another on the same partition, the file permissions are retained. Windows 2000 updates the directory allocation table to the new directory location.
When a file is moved between two different partitions, Windows 2000 first copies the file to the new location. Upon successful completion of the copy, Windows 2000 deletes the original file. A new file is being created, so the rules for new file creation apply and the target directory's permissions are inherited.

*Assigning NTFS Permissions
Let's see what happens when you change NTFS permissions on files and folders.
We'll begin with a simple text file.

Right-click on the file in Windows Explorer and select Properties from the context menu.

As you can see, Windows 2000 defaults to assigning full permissions to the Everyone group for this file.

The permissions are inherited from the folder in which we created the file. To remove them, clear the check box that says Allow inheritable permissions from parent to propagate to this object.

You can then customize permissions by selecting the appropriate Allow and Deny check boxes.
In this case, we will allow everyone to read the file, but not make changes to it.

With these settings, it is still possible to open the file.

However, if you add a line of text and then try to save it, you get this message.

Windows 2000 allows even more detailed control over file and folder permissions, which you can access through the Advanced tab in the Properties dialog box.

You can then view and edit a more granulated list of permissions.









In this lesson, you learned about the Windows 2000 file system (NTFS) and its permissions features.
You learned about the permissions available in NTFS and the effect they have when applied to files and folders.
You also learned how permissions are inherited in NTFS.
Finally, you learned to set permissions for a file using Windows Explorer.

Lesson 14. Remote File Access

In addition to local file permissions, Windows 2000 allows you to set permissions to control access to remote files and folders.
After completing this lesson, you should be able to:

Remote access to files and directories is provided through share permissions.
A share is a network access point through which remote users can access files. When configuring these shares, you set the permissions.

The application of permissions on shares works similarly to the application of permissions on NTFS. The primary difference is the lack of finely granulated permissions.
You can assign only no access, read, change, or full control permissions. The permissions yielded are indicated below.
Examine the following table
Permission Allows
Full Control Change file permissions.
Take ownership of files on NTFS volumes.
Perform all tasks allowed by the change permission.
Modify Create folders and add files.
Change data in, and append data to, files.
Change file attributes.
Delete folders and files.
Perform all tasks permitted by the read permission.
Read & Execute Display folder and file names.
Display file data and attributes.
Run program files.
Change to folders within a folder.
No Access Establish only a connection to the shared folder. Access to the folder is denied and the contents do not appear. This permission overrides all others.


Share permissions and share points must be assigned carefully.
Because permissions are assigned only to the share points, any files or directories accessible under that share point are accessed with the same permissions as the share point itself.

Remember the difference between a share point and the contents of a directory and its subdirectories.
Except in the case of NTFS permissions, the access token Windows 2000 grants to a user concerning a share allows the user access to all subdirectories of the shared directory. This fact can lead to some access security problems if it is not properly understood.

Consider the C:\CORP\PUB directory shown here.
Suppose the \CORP share allows Everyone access.
This share also contains a subdirectory named \PUB.
However, notice also that this subdirectory has also been given its own share name of Pub. Suppose that, contrary to its name, the Pub share allows access only to a user named Sandi.

As expected, only the user named Sandi can directly access this share by using its UNC, or by clicking its share icon. If James tries to directly access the Pub share (\\machine\Corp\Pub), he will be denied access.
However, he (or anyone else) can still view the restricted directory by connecting to the \Corp\ share, and then using Network Neighborhood or My Network Places to move down to the \Pub subdirectory.
The Corp share point gives all access to anything below the shared directory. This access is possible because share-level access tokens apply to all subdirectories.

*Combined Permissions
Windows 2000 permissions are designed with the intention of using NTFS and share permissions together.
Because Windows 2000 is designed as a server, users will rarely access the files directly. Certainly, share security by itself is insufficient for most security needs, so both need to be used.

When you combine share and NTFS permissions, the more restrictive of the two sets of rights is used.
The result is the ability to use share permissions for broad user permissions when connecting to a share point. The NTFS permissions can then be used to further tighten permissions on a much more granular basis.













In this lesson, you learned how share permissions are used to allow remote file access on Windows 2000 systems.
You learned about the four Windows 2000 remote access permissions. You also learned how share permissions are inherited.
Finally, you learned what happens when local and remote permissions are combined.

Lesson 15. Linux File Systems

In UNIX systems, information is always stored as a file.
After completing this lesson, you should be able to:

In all UNIX systems, information — even network connections and directories — is always stored as a file. This file has a name associated with it. The file system is the basic manner in which Linux security is enforced.
Let's look at how permissions are handled in a standard UNIX file system. These permissions control what users may access and how they may access it.

*Files
Linux reads and writes data to files, which are maintained in a tree-like structure. Since the beginning, Linux systems have allowed long file and directory names.
All files have an inode, which describes all the statistical and logistical information that the system knows about a file or directory.

Some of the data the inode contains is as follows.


*UIDs and GIDs
File permission bits and controls apply in a discretionary manner to all objects, including files, directories and executables (such as programs).
This information is kept in the inode portion of the file system where the objects are located. A certain portion of each file's inode (depending upon actual vendor implementation) is set aside for these bits.
Usually this portion is 16 bits and is handled collectively as an entity. Nine bits are used for the file modes (read, write, execute and none bits). Three additional bits describe or state how these bits may work with certain UIDs and GIDs that are also associated with a file.

UIDs are uniquely indicated in the system's /etc/passwd file. The GIDs are uniquely described in the system's /etc/group file.
When someone begins using the system, a process is started for each user invocation. This process is tracked by the kernel and is then assigned to a resource such as memory, CPU, I/O, etc.

To help the kernel track this information, each process must have a process identifier (PID).
Each PID has in its table four other numbers. Two are the familiar UID and GID. Additionally, an extra pair of UID and GID numbers are also assigned, called the effective UIDs and GIDs.
The process may occasionally need to acquire an identity different from its primary UID and GID (such as becoming another user or boosting its privilege level to change that user's password). In such an instance, the effective UID and GID are different from the initial set of values. These effective values are evaluated by the Linux kernel to grant security access.

*The Set Bits
UNIX allows programs to assume another UID or GID when running.
A program that changes its UID is called an SUID (set-UID or setuid) program; similarly, when a program changes its GID, it is called an SGID (set-GID or setgid) program.
One situation in which a program changes its UID or GID is when the SUID or SGID permission bit is set in the file permissions. A program can have both of these bits set at the same time.
The setuid bit is the twelfth bit, the setgid bit is the eleventh bit, and the sticky bit is usually the remaining tenth bit in the inode 16-bit word.

When a setuid program is executed, its effective UID becomes that of the user who owns the file containing that program. This UID may differ from the UID of the person (or user) who is running it.
The following table illustrates the extra set bits that may be used for changing effective UIDs or GIDS.
Examine the following table
Permission Bit Meaning
S Indicates that setuid is on, but execution bit (x) is not set. The numeric permission for this bit is 4000.
s When set in file's owner component, indicates to Linux kernel that if executed, its effective UID should be set to that of the owner. The numeric permission for this bit is 4100.
S Indicates that setgid is on, but the group execution bit (x) is not set. The numeric permission for this bit would be at least 2000.
s When set in file's group component, indicates to Linux kernel that upon execution, effective GID should be set to that group. The numeric permission for this bit would be at least 2100.
T Upon program termination, indicates that program will not be immediately removed from Linux swap/paging area. This option is obsolete. Modern UNIX systems ignore this bit and make their own decisions about memory management. This bit will be capitalized The numeric permission for this bit would be at least 1000.
t When set on a directory, a user can delete a file in that directory only if she has write permission for that file. Normally, only write permission on the directory is needed. The numeric permission for this bit would be at least 1001.


Programs that need extra permissions use the SUID/SGID features. For example, the passwd program, which must write to the system password file, needs to run with root permissions to perform that task.
Because the SUID/SGID mechanism temporarily grants a user more permissions than she is normally entitled to, all programs in a system which have these bits set must be monitored and examined for changes.

*The ls Command
Let's take a look at a typical listing.
The ls command is the most commonly used UNIX command, and is used to look at file and directory permissions.

The ls command shown here (ls -ld .) takes a listing of the filename called "." (dot) which is usually the current directory.
In this case, we are logged on as the root.

The output line from our ls command (above) has the elements listed below.
Examine the following table
Output Symbol Meaning
d Indicates directory
r Read access to owner (whose login name is root)
w Write access to owner
x For directory, implies that search access or capability is granted to owner
- Read access is not available to group (in this case, staff)
- No write permission is granted to group
- Search permission for this directory is not granted to group
- Read permission is denied to others (or everybody)
- No write permission exists for others
- Search permission in this directory is not available to others
root Owner's login name
root Group to which this user belongs. Linux assigns users to their own group to help simplify group administration. With groups named after users, it is possible to know exactly which groups you can work with; as long as you know a user's name, you know a group name, as well.
4096 Size (in bytes) of this directory
Time Stamp Date on which the size last changed
7:59 Time at which that change occurred
./ File name to which all this information pertains


The ls command shown above lists the information about a single file (in this case, /etc/syslog.conf).
Its components are listed below.
Examine the following table
Field Value Meaning
- Plain file.
r Read access granted to owner.
w Write access set to owner.
- No "x" usually indicates plain file; i.e., not executable.
r Read access granted to group.
- No write permission granted to group.
- No execute permission to any members of group.
r Read access available to others (everybody).
- No write permission to world.
- No execute permission to world.
1566 File size.
Time Stamp Date on which file was created. When time stamp exceeds six months, file-listing program or utility will convert to year display.


The ls command shown here illustrates the typical permissions on a system file (in this case /dev/tty). All screen typing is echoed to this file, and messages sent by other programs are written to it.
The permissions are explained below.
Examine the following table
File Value Meaning
c Indicates a character device. Character devices are often video monitors (as in this case), or printers.
rw Read and write access granted to owner.
rw- Read and write access granted to group.
rw- Read and write access available to all others.
1 Reference count (indicates unique file).
root Actual owner of this file.
root The group to which file belongs.
5 File size (in bytes).
Time Stamp Date on which file was first created.
/dev/tty Location of file.


*The umask Command
Now that you understand some of the various mode bits for a file (or directory) in Linux, we can look at the ways in which they can be changed.
The umask command is used widely in all UNIX systems to set subsequent file creation mode bits. It is also used in login profiles to set up default permissions.

The mode value bits are summarized in the table below.
Usually the default permissions are 666 (i.e., read and write to owner, group and others) for plain files. Each bit pattern (or octal value) is assigned to each component of the file's three values (owner, group and others). The default permissions for a directory and an executable program may be 777 (i.e., read, write, and search execute for owner, group, and others).
Examine the following table
Mode Values Meaning
7 Read, write, and execute
6 Read and write
5 Read and execute
4 Read only
3 Write and execute
2 Write
1 Execute
0 No mode bits (i.e., access absent)


At sites where users expect to protect their data from inspection by other users, all users should have a umask value of 077.
For users working on group projects, a umask value of 037, which permits group access to files by default, may be a better choice.

*The chmod Command
The chmod command is used to manipulate file permissions. It may be applied in two ways:

  host# chmod  mode values  filename  

When used in absolute mode, chmod looks like this:
  host# chmod 666 filename  
Here, the permission mode bits are being absolutely applied to a filename. Variations are based upon the mode bits outlined previously in our discussion of the ls command, with bits applied to each component (e.g., owner, group, and others).

When used in symbolic mode, chmod looks like