ESTUDIOS PARAMÉTRICOS RELATIVOS A LA PIRÓLISIS

Shares are directories or volumes made available from a workstation or server for access by other computers in the network. Shares can be publicly available, or they can be given a list of users or groups with permission to access them. Shares use share-level security, which allows you to control permissions for shared directories, but not for anything contained within the directory. File-level security is superior to share-level security, but can only be used on NTFS volumes.

shares

Constructs used by the Server service to determine how users should be able to access folders across the network.

Although you can set up a reasonably secure small network with shares, share security techniques don’t really scale well for larger networks and environments where security is required, because a new share must be created whenever security requirements change and because multiple shares with different security levels can be applied to the same directories. Using and Securing Shares

File sharing is one of the most important uses of a network. Any directory on any workstation or server in the network can be set up as a shared directory. Although shares don’t have the same level of security as NTFS directories on a dedicated server, Windows NT does provide a simple set of security features for shared directories.

Creating a Share

You can create a share with any volume or any directory within a volume. You can create shares in either NTFS or FAT partitions, although shares in NTFS partitions can be made more secure. To create a share, right-click a drive or a directory in an Explorer window and select the Sharing option. The Sharing Properties dialog box is displayed.

From this dialog box you can specify these options:

Not Shared/Shared As Specify whether the volume or directory should be shared.

Share Name Choose a name for the share. This name will appear as a directory name when users view a directory listing for the server. If the share will be accessed by users running Windows 3.x, or if your users use

DOS applications, be sure to use a DOS-compatible name for the share (8 characters or less). Comment Enter a description of the share’s purpose, or other information. (This is optional.) The contents of this field are displayed in the Explorer window to the right of the share name if the user selects the Details view.

User Limit If Maximum Allowed is selected, the number of users accessing the share is limited only by the Windows NT license. If a number is specified, only that many concurrent users can access the share.

Permissions Clicking this button displays a dialog box that allows you to change permissions for the share, as described later in this chapter.

Caching Click this button to configure caching options for this share. Offline caching allows users to store the file locally on their hard disk so it’s available even if they’re not online or if the server is unavailable.

When a directory or drive is shared, it is listed in Explorer with a special icon that shows a hand underneath the drive or folder icon.

Accessing Shares

Although a server might have several shares configured—some entire volumes, some directories several levels deep—they all appear to users as a single listing under the server’s name. Users can navigate to the server name using My Network Places icon, then open it to display a list of shares. Unfortunately, share names are not shown automatically in the Active Directory when you double-click on a computer—they must be manually added in the Active Directory hierarchy.

As an example, suppose we created several shares, including VOL F for an entire NTFS volume, and IE4 for the \Program Files\Plus!\Microsoft Internet directory. A user who navigated to the server through My Network Places or Network Neighborhood would see a flat list of shares.

To make access to shares more convenient for users in the workgroup, you can create Desktop shortcuts to particular directories. You can also map a drive letter on the workstation to the share. This method has the benefit of fooling not only users into thinking it’s a local drive, but also DOS and Windows applications that otherwise might not support network access. To map a drive to a share, right-click the My Network Places icon and then select Map Network Drive. Mapping drives is not normally necessary to access files from the Desktop Explorer or from Win32 applications.

To use this dialog box, choose a local drive letter, and then choose a server name and path to map the drive to. In Windows NT, the window at the bottom of the dialog box displays a list of servers and shares. In Windows 2000 and XP, you click the Browse button to search for a server and share. Select the Reconnect at Logon option to have the drive mapped each time the user logs on.

As an administrator, you have another option for displaying a list of shares on a server. The Computer Management snap-in’s Shared Folders extension allows you to list shares on the local machine, add or remove shares, and monitor users who are currently accessing shares. The tool is available in the Administrative Tools folder and works just like every other MMC snap-in.

Default Shares

Windows automatically creates some shares, called administrative shares, which are accessible only to administrators and the operating system itself. These shares are used for remote administration and communication between systems.

Each drive is automatically given an administrative share, with the share name being the drive letter followed by a dollar sign. The ADMIN$ share is connected to the \WINNT directory on each server. There is also an IPC$ share, used for inter-process communication between Windows NT servers, and a PRINT$ share, which shares printer information between servers. Domain controllers have a SYSVOL$ share used to distribute group policies, scripts, and installation packages.

As you’ve probably noticed, these shares don’t appear in the browse lists that you can view from the Explorer. The only way to list them is with the Computer Management snap-in, which was described in the previous section.

Tip You can create your own “administrative” shares. Any share name ending with a dollar sign ($) will be hidden from browse lists. Users (administrators or not) can access the share if they know its exact name.

Administrative shares present a potential security risk. A hacker who has gained access to the Administrator account on a single workstation in the workgroup can access the system drives of other workstations, effectively allowing administrator-level access to the entire workgroup. You can improve security by disabling the administrative shares. You can remove the shares from each drive’s Properties window, or use the Shared Folder extension’s Stop Sharing option. It’s best to disable all of these and then add a share for any specific drives or directories that need to be available across the network.

Share versus File Security

Share level security is similar to file system security, but not nearly as sophisticated (or as secure) because Share Access Control Entries can be applied only to the share as a whole. Security cannot be customized within a share.

There is one significant advantage of share-level security: It works with any shared directory, whether it’s on an NTFS or FAT volume. Share level security is the only way to secure FAT directories. However, the share permissions you set only affect remote users. Users logged onto the machine locally can access anything on a FAT volume, shared or not. Share level security also does not apply to users logged on locally or to Terminal Services clients. Share Permissions

To set permissions for a share, click the Permissions button from the Sharing Properties dialog box. By default, the Everyone built-in group is given Full Control access to the share— in other words, share security is not implemented by default. The first thing you should do to secure a share is remove the Everyone group from the list. You can then add any number of users or groups, and give them specific permissions. The following are the permissions available for shares, and each can be allowed or denied:

Read Allows users to list contents of the directory, open and read files, and execute programs. Change Allows users to create, delete, or modify files, as well as do everything the Read permissions allow.

Full Control Allows all Read and Change permissions. In addition, users can change permissions and change file ownerships.

IPSec

Windows can be configured to use IPSec to secure communications between computers. Using default IPSec policy rules, you can configure clients to allow encryption and configure servers to request encryption or require encryption. A server that requires encryption will only communicate with hosts that have a valid SA that can be negotiated using IKE.

Windows 2000 supports both Authenticated Headers (AH) and Encapsulating Security Payload (ESP) in transport mode. Windows 2000 does not support ESP tunnel mode (IP encapsulation). This means that a Windows host cannot act as a bastion host and encrypt the communication stream between two private networks, it can only encrypt communications between itself and other hosts.

Windows 2000 uses IKE to negotiate encryption protocols and keys amongst hosts. As with any implementation of IKE, a private key is used for IKE authentication. In the case of Windows 2000, the private key can be a valid Kerberos ticket, a Certificate, or a manually configured secret key.

Kerberos tickets Make IPSec authentication seamless amongst hosts in the same domain, but only work when all the participants are running Windows 2000 or higher.

Certificates Are appropriate for use in extranets, situations where trust does not transit between domains, communication with non-Windows hosts that can utilize certificates, or in environments where a Public Key Infrastructure is in place.

Manual secret keys Are useful for encrypting communications between hosts that are not in domains and not in PKI environments where communications with non-Windows hosts are required, or when compatibility problems prevent the use of Kerberos or certificates.

Windows 2000 creates filters to determine which SA a particular host belongs to, in order to encrypt the communications with that host. These filters can be edited by the administrator to fix problems and for further customization or refinement. Automatically created filters tend to have problems if the host has more than one network adapter (as all Remote Access servers do) and in other situations.

Problems with IPSec

Microsoft believes that IPSec is the future of all communications amongst hosts in a network and sees it as something of a panacea for security problems. While it certainly could help with a number of problems, it’s not compatible with more important security mechanisms like NAT and Proxy service, and it prevents firewalls from seeing the interior of TCP and UDP packets, thus eliminating their ability to filter based on packet type. This creates a conundrum for security administrators: If you allow IPSec to transit your firewall, you eliminate the firewall’s ability to filter IPSec traffic.

Because IPSec transport mode doesn’t play well with firewalls or private addressing allowed by NAT, which are far more important to holistic security, IPSec really only has a purpose in securing administrative connections to public hosts and in environments (like the military) where secure communications are required on the interior of already public networks. For most users, host-to-host IPSec will not significantly improve security and will dramatically increase the administrative burden.

IPSec puts heavy loads on servers (which must maintain numerous simultaneous encrypted streams), so extra processing power is required. In the case of terminal service and database servers, CPU power is at a premium, so requiring encryption will reduce the number of users that a server can support.

In sum, these problems mean that host-to-host IPSec is going to remain a network-to-network encryption as implemented by IPSec tunnel-mode VPN devices, not a host-to-host security service as implemented by Windows 2000’s IPSec transport-mode. Once you have network- to-network communications established, there’s little reason for most users to be concerned with additional encryption inside the private network.

Review Questions

1. Upon what foundation is Windows security built? 2. Where is the list of local computer accounts stored? 3. What represents user accounts in Windows security? 4. What process manages logging in?

5. What protocol is used to authenticate a user account in a Windows 2000 domain? 6. How is the user’s identity passed on to running programs?

7. When you attempt to access a file, what does the LSA compare your access token to in order to determine whether or not you should have access?

8. What special right does an object’s owner possess?

9. For what purpose is the System Access Control List used? 10. What is the difference between a right and a permission?

11. What does the term inheritance mean in the context of file system permissions? 12. Where are user accounts stored in a domain?

13. In a Kerberos authentication, can a user in Domain A logon to a computer in Domain C if Domain C trusts Domain B and Domain B trusts Domain A?

14. What is the primary mechanism for controlling the configuration of client computers in Windows?

15. Can more than one group policy be applied to a single machine? 16. Does share security work on FAT file system shares?

Answers

1. Mandatory user logon is the foundation of security in Windows. 2. The local computer accounts are stored in the registry.

3. Security Identifiers (SIDs) represent user accounts. 4. The WinLogon process manages the login process.

5. Kerberos is used to authenticate user accounts in Windows 2000 domains.

6. The user’s identity is passed to running programs by the inheritance of the access token from the launching program.

7. The LSA compares your access token to the object’s security descriptor (Access Control List) in order to determine whether or not you should have access.

8. An object’s owner has the right to change the object’s permissions irrespective of a user’s permissions to the object.

9. The System Access Control List is used too audit various types of access to an object. 10. Rights affect many or all objects, whereas permissions are specific to each object.

11. Inheritance refers to objects receiving of a copy of the containing folder’s ACL when they are created.

12. User accounts are stored in the Active Directory. 13. Yes. In Kerberos, trusts transit domain relationships.

14. Group policy is the primary mechanism for controlling the configuration of client computers in Windows.

15. Yes. Early policy changes are overwritten by later policy changes when multiple policies are applied.

16. Yes. Share security works on FAT file system shares.