|
The Windows NT alerter and messenger services enable a user to send pop-up messages to other users. A network administrator may consider this an unnecessary risk due to the fact that these types of services have been known to be used in social engineering attacks. Some users might actually respond to a request to change their password, create a share, or otherwise open holes in the network. A side effect of running this service is that it causes the name of the current user to be broadcast in the NetBIOS name table, which gives the attacker a valid user name to use in brute force attempts.
Unbind Unnecessary Services from Your Internet Adapter Cards
|
Completed
|
Not implemented
|
Not applicable
|
STATUS
|
|
|
|
Use the Bindings feature in the Network application in Control Panel to unbind any unnecessary services from any network adapter cards connected to the Internet. For example, you might use the Server service to copy new images and documents from computers in your internal network, but you might not want remote users to have direct access to the Server service from the Internet.
If you need to use the Server service on your private network, disable the Server service binding to any network adapter cards connected to the Internet. You can use the Windows NT Server service over the Internet; however, you should fully understand the security implications and comply with Windows NT Server Licensing requirements issues.
When you are using the Windows NT Server service you are using Microsoft networking (the server message block [SMB] protocol rather than the HTTP protocol) and all Windows NT Server Licensing requirements still apply. HTTP connections do not apply to Windows NT Server licensing requirements.
For Windows NT systems with direct Internet connectivity and have NetBios, there are two configuration options:
• Configure the NT system on the Internet outside the corporate firewall. You can also accomplish this by blocking ports 135, 137 and 138 on TCP and UDP protocols at the firewall. This ensures that no NetBIOS traffic moves across the corporate firewall.
• Configure the protocol bindings between TCP/IP, NetBIOS, Server and Workstation services using the network control panel. By removing the bindings between NetBios and TCP/IP, the native file sharing services (using the Server and Workstation services) will not be accessible via TCP/IP and hence the Internet. These and other NetBios services will still be accessible via a local LAN-specific, non-routable protocol (ex: NetBEUI) if one is in place. To accomplish this use the Network Control Panel applet. Select the Bindings Tab and disable the NetBios bindings with TCP/IP protocol stack.
A Windows NT system with direct Internet connectivity needs to be secured with respect to other services besides NetBios access, specifically Internet Information Server
NetBIOS over TCP/IP should normally be disabled for a firewall or web server. The following is a list of the ports used by NBT.
netbios-ns 137/tcp NETBIOS Name Service
netbios-ns 137/udp NETBIOS Name Service
netbios-dgm 138/tcp NETBIOS Datagram Service
netbios-dgm 138/udp NETBIOS Datagram Service
netbios-ssn 139/tcp NETBIOS Session Service
netbios-ssn 139/udp NETBIOS Session Service
Enhanced Protection for Security Accounts Manager Database
|
Completed
|
Not implemented
|
Not applicable
|
STATUS
|
|
|
|
The Windows NT Server 4.0 System Key hotfix (included in Service Pack 3) provides the capability to use strong encryption techniques to increase protection of account password information stored in the registry by the Security Account Manager (SAM). Windows NT Server stores user account information, including a derivative of the user account password, in a secure portion of the Registry protected by access control and an obfuscation function. The account information in the Registry is only accessible to members of the Administrators group. Windows NT Server, like other operating systems, allows privileged users who are administrators access to all resources in the system. For installations that want enhanced security, strong encryption of account password derivative information provides an additional level of security to prevent Administrators from intentionally or unintentionally accessing password derivatives using Registry programming interfaces.
Please refer to Knowledge Base article Q143475 for more details on SysKey feature and how it can be implemented on a Windows NT installation.
Disable Caching of Logon Credentials during interactive logon.
|
Completed
|
Not implemented
|
Not applicable
|
STATUS
|
|
|
|
The default configuration of Windows NT caches the last logon credentials for a user who logged on interactively to a system. This feature is provided for system availability reasons such as the user’s machine is disconnected or none of the domain controllers are online.
Even though the credential cache is well protected, in a highly secure environments, customers may want to disable this feature. This can be done by setting the following registry key:
Hive:
|
HKEY_LOCAL_MACHINE
|
Key:
|
Software\Microsoft\Windows NT\CurrentVersion\Winlogon
|
Name:
|
CachedLogonsCount
|
Type:
|
REG_DWORD
|
Value:
|
0
|
How to secure the %systemroot%\repair\sam._ file
|
Completed
|
Not implemented
|
Not applicable
|
STATUS
|
|
|
|
By default, the SAM._ file and \repair directory has the following permissions;
Administrators: Full Control
Everyone: Read
SYSTEM: Full Control
Power Users: Change
1.From within Explorer, highlight the SAM._ file, right click, choose properties, security, permissions. Remove all privilege from this file.
2.From a DOS prompt, execute the following;
cacls %systemroot%\repair\sam._ /D Everyone
This will deny the group Everyone permission to the file, ensuring that no other permission (i.e. inheritted permissions from a share) can override the file permission.
3.Whenever you need to update your ERD, first execute the following from a DOS prompt;
cacls %systemroot%\repair\sam._ /T /G Administrators:C
This will grant Administrators change permission to update it during the ERD update.
4.Once the ERD has been updated, execute the following from a DOS prompt;
cacls %systemroot%\repair\sam._ /E /R Administrators
This will once again remove the permissions for Administrator
How to enable auditing on password registry keys
First you have to make sure auditing is enabled. Start User Manager, Policies, Audit, and click "Audit These Events".
By default, Windows NT does not identify any users or groups to audit on any objects within the system. Auditing can add performance overhead to your system depending on the available resources, so care should be taken in determining what and whom to audit. For a full description of auditing in Windows NT, I recommend the Microsoft Press book "Windows NT 3.5 - Guidelines for Security, Audit, and Control", ISBN 1-55615-814-9. Despite its title it is still the most comprehensive coverage of auditing that I have read. For the sake of this example, we will simply check every Success and Failure checkbox.
Close the dialog.
Now for a little known trick. While logged on as Administrator, ensure that the Schedule service is set to start up as the System account. Once set, start the Schedule service.
Check the time, and then open a DOS prompt. At the DOS prompt, type in the following; at 22:48 /interactive "regedt32.exe" where 22:48 gets replaced with the current time plus 1 minute (or 2 or whatever amount of time you think it will take you to type in the command).
At the designated time, regedt32.exe will fire up and appear on your desktop. This incarnation of regedt32.exe will be running in the security context of the user SYSTEM. As such, you will be able to see the entire registry, every key within the SAM or Security trees. BE VERY CAREFUL HERE. It is important to note that when running an applicatin as SYSTEM, it does so attempting to use null session for credentials. Null session support has been disabled by default in all versions of Windows NT after 3.1, therefore any attempt to connect to non-local resources as this security context will fail. An Administrator could enable null session support through the registry, but such a configuration is strongly discouraged.
All we want to do is enable auditing on the designated keys, nothing else. To this end, we highlight the HKEY_LOCAL_MACHINE windows within regedt32. Next highlight the SAM tree. Choose the Security menu item, then Auditing.
Click on the Add button and choose Show Users.
I'm going to recommend that you add the SYSTEM user, the group Domain Admins, and the user Administrator. You want to cover any account which has the right to;
"Take ownership of files or other objects"
"Back up files and directories"
"Manage auditing and security log"
"Restore files and directories"
"Add workstations to domain"
"Replace a process level token"
Click the Audit Permission on Existing Subkeys
Next, click in the Success and Failure checkboxes for the following entries; - Query Value - Set Value - Write DAC - Read Control
Choose OK, and then Yes.
Repeat the process for the Security tree.
Close REGEDT32, and stop the Schedule service. You will want to set the Schedule service to use a userID for startup which you create, rather than SYSTEM, in future. Take this opportunity to create such a user and change the startup for Schedule.
You will now have applied auditing to the entire SAM ensuring you'll be notified via the Event Logger of any failed or successful access to your sensitive information by the only accounts which have the ability to access such information. The issue of what to do when/if you discover event notifications is beyond the scope of this document. Part of a good security policy is an appropriate audit policy which would dictate how the event logs are reviewed, how the information is verified, and what actions should be taken for each possible event.
|
