Secure File Sharing
|
Completed
|
Not implemented
|
Not applicable
|
STATUS
|
|
|
|
The native Windows NT file sharing service is provided using the SMB-based server and redirector services. Even though only administrators can create shares, the default security placed on the share allows Everyone full control access. These permissions are controlling access to files on down level file systems like FAT which do not have security mechanisms built in. Shares on NTFS enforce the security on the underlying directory it maps to and it is recommended that proper security be put via NTFS and not via the file sharing service.
Also note that the share information resides in the registry which also needs to be protected as explained in a section earlier.
Service Pack 3 for Windows NT version 4.0 includes several enhancements to SMB based file sharing protocol. These are:It supports mutual authentication to counter man-in-the-middle attacks.
It supports message authentication to prevent active message attacks.
These are provided by incorporating message signing into SMB packets which are verified by both server and client ends. There are registry key settings to enable SMB signatures on each side. To ensure that SMB server responds to clients with message signing only, configure the following key value:
Hive:
|
HKEY_LOCAL_MACHINE\SYSTEM
|
Key:
|
System\CurrentControlSet\Services\LanManServer\Parameters
|
Name:
|
RequireSecuritySignature
|
Type:
|
REG_DWORD
|
Value:
|
1
|
Setting this value ensures that the Server communicates with only those clients that are aware of message signing. Note that this means that installations that have multiple versions of client software, older versions will fail to connect to servers that have this key value configured.
Similarly, security conscious clients can also decide to communicate with servers that support message signing and no one else.
Hive:
|
HKEY_LOCAL_MACHINE\SYSTEM
|
Key:
|
System\CurrentControlSet\Services\Rdr\Parameters
|
Name:
|
RequireSecuritySignature
|
Type:
|
REG_DWORD
|
Value:
|
1
|
Note that setting this key value implies that the client will not be able to connect to servers which do not have message signing support.
Please refer to Knowledge Base article Q161372 for further details on SMB message signing enhancements.
Windows NT version 4.0 Service Pack 3 also includes another enhancement to SMB file sharing protocol such that by default you are unable to connect to SMB servers (such as Samba or Hewlett-Packard (HP) LM/X or LAN Manager for UNIX) with an unencrypted (plain text) password. This protects from sending clear text forms of passwords over the wire. Please refer to Knowledge base article Q166730 if you have any reasons to allow clients to send unencrypted passwords over the wire.
Additionally, customers may want to delete the administrative shares ($ shares) if they are not needed on an installation. This can be accomplished using “net share” command. For example:
C:\> net share admin$ /d
Auditing
Auditing can inform you of actions that could pose a security risk and also identify the user accounts from which audited actions were taken. Note that auditing only tells you what user accounts were used for the audited events. If passwords are adequately protected, this in turn indicates which user attempted the audited events. However, if a password has been stolen or if actions were taken while a user was logged on but away from the computer, the action could have been initiated by someone other than the person to whom the user account is assigned
When you establish an audit policy you’ll need to weigh the cost (in disk space and CPU cycles) of the various auditing options against the advantages of these options. You’ll want to at least audit failed log on attempts, attempts to access sensitive data, and changes to security settings. Here are some common security threats and the type of auditing that can help track them:
Threat
|
Action
|
Hacker-type break-in using random passwords
|
Enable failure auditing for log on and log off events.
|
Break-in using stolen password
|
Enable success auditing for log on and log off events. The log entries will not distinguish between the real users and the phony ones. What you are looking for here is unusual activity on user accounts, such as log ons at odd hours or on days when you would not expect any activity.
|
Misuse of administrative privileges by authorized users
|
Enable success auditing for use of user rights; for user and group management, for security policy changes; and for restart, shutdown, and system events. (Note: Because of the high volume of events that would be recorded, Windows NT does not normally audit the use of the Backup Files And Directories and the Restore Files And Directories rights. Appendix B, “Security In a Software Development Environment,” explains how to enable auditing of the use of these rights.)
|
Virus outbreak
|
Enable success and failure write access auditing for program files such as files with .exe and .dll extensions. Enable success and failure process tracking auditing. Run suspect programs and examine the security log for unexpected attempts to modify program files or creation of unexpected processes. Note that these auditing settings generate a large number of event records during routine system use. You should use them only when you are actively monitoring the system log.
|
Improper access to sensitive files
|
Enable success and failure auditing for file- and object-access events, and then use File Manager to enable success and failure auditing of read and write access by suspect users or groups for sensitive files.
|
Improper access to printers
|
Enable success and failure auditing for file- and object-access events, and then use Print Manager to enable success and failure auditing of print access by suspect users or groups for the printers.
|
|
