1. Module 8: Providing Secure Access to Non-Microsoft Clients

2. Overview Providing Secure Network Access to UNIX Clients
Providing Secure Network Access to NetWare Clients
Providing Secure Network Access to Macintosh Clients
Securing Network Services in a Heterogeneous Network
Monitoring for Security Breaches

3. Many networks, especially networks in enterprise organizations, consist of computers that use different operating systems. Microsoft® Windows® 2000 is designed to interoperate with different types of network clients, including UNIX, Novell NetWare, and Apple Macintosh clients. Providing non-Microsoft clients with access to a Windows 2000 network presents unique challenges to the design of a secure network. Non-Microsoft clients must use protocols supported by Windows 2000 to connect to a Windows 2000 network. The protocols and related file systems that heterogeneous clients use must be properly configured to provide maximum security while still permitting access to the Windows network.

4. At the end of this module, you will be able to:
Identify the risks associated with allowing UNIX clients access to a Windows 2000 network.
Identify the risks associated with allowing NetWare clients access to a Windows 2000 network.
Identify the risks associated with allowing Macintosh clients access to a Windows 2000 network.
Secure common network services that are operating in a heterogeneous network.
Monitor a heterogeneous network for security breaches and identify the risks of unauthorized network monitoring.

5. Providing Secure Network Access to UNIX Clients
Interoperating with a UNIX Network
Authenticating UNIX Clients
Securing SMB-based File Access
Securing NFS-based File Access
Securing TCP/IP-based Applications

6. Microsoft offers utilities and tools that allow UNIX clients to access a Windows 2000-based network. UNIX clients must be authenticated to maintain the security of your network. You must secure the common software, file systems, and protocols that UNIX clients use to access resources on a network. Three of the most common and most important file systems and protocols are Server Message Block (SMB), Network File System (NFS), and Transmission Control Protocol/Internet Protocol (TCP/IP).

7. In this lesson you will learn about the following topics:
Interoperating with a UNIX network.
Authenticating UNIX clients.
Securing SMB-based file access.
Securing NFS-based file access.
Securing TCP/IP-based applications.

8. Interoperating with a UNIX Network
Services for UNIX includes:
NFS software
Network administration tools
Account management tools

9. Microsoft Services for UNIX version 2
Microsoft Services for UNIX version 2.0 includes tools that integrate UNIX and Windows networks. You can use Services for UNIX to improve the interoperability between UNIX clients and a Windows 2000 network.
Services for UNIX integrates UNIX clients into a Windows 2000 network, and includes:
NFS software
Network administration tools
Account management tools

10. NFS software.
NFS is a file system commonly used by UNIX clients. The NFS client software included with Services for UNIX allows Windows 2000-based clients to connect to UNIX NFS servers as if they were Windows 2000 shared folders. The NFS server software included with Services for UNIX allows UNIX clients to connect to file resources on a Windows 2000-based server. The NFS gateway software allows Windows 2000-based computers, without using any special software, to access UNIX NFS resources.

11. Network administration tools.
Services for UNIX provides important tools to enhance and simplify the administration of your network, including a Telnet client, a Telnet server, the Services for UNIX Microsoft Management Console (MMC), and ActivePerl. ActivePerl enables existing and new scripts to use the Windows Management Instrumentation (WMI) to automate network administration tasks.

12. Account management tools.
Services for UNIX provides tools to help simplify the account management in a mixed Windows and UNIX network. These tools include:
Network Information System (NIS) Migration wizard. Provides the ability to move UNIX NIS source files from the NIS domain to the Active Directory™ directory service in Windows 2000 to consolidate account management.
Server for NIS. Allows a Windows 2000 domain controller to act as the primary server for NIS, integrating NIS domains with Windows domains, and allowing administrators to manage both domains by using Active Directory.
Password synchronization (two way). Provides the ability to synchronize passwords for both platforms, so that users can more easily maintain one password for both Windows and UNIX.
User Name Mapping service. Associates Windows and UNIX user names, allowing users who are using Windows 2000-based computers to connect to NFS resources without requiring the users to log on to UNIX systems separately.

13. Authenticating UNIX Clients
Authentication
UNIX Client
Windows 2000
Server
Authenticate by Using:
Kerberos V5 protocol
NTLM protocol
Certificate-based authentication
Clear-text authentication

14. Windows 2000 supports several industry standards for authenticating UNIX clients. The type of authentication used depends directly on the applications used by the UNIX clients. Windows 2000 supports the following types of authentication for UNIX clients.
Kerberos version 5 protocol
NTLM protocol
Certificate-based authentication
Clear-text authentication
Note: Earlier versions of Samba require that clear-text authentication be enabled to authenticate with Active Directory. Only Samba and later can authenticate by using NTLM.

15. Kerberos version 5 protocol
UNIX clients can use the Kerberos V5 protocol for authentication. UNIX clients authenticate by using Windows 2000 domain controllers as their Kerberos Key Distribution Center (KDC), or by configuring an inter- realm Kerberos trust between a Windows 2000 domain and a Kerberos realm. Both methods require that user accounts be created in Active Directory for the UNIX users, and that account mappings be created between UNIX accounts and Windows 2000 user accounts. The account mapping associates a Windows 2000 security identifier (SID) to an account defined in the UNIX domain.

16. NTLM protocol
UNIX clients that use SMB and Common Internet File System (CIFS), such as LAN Manager for UNIX and the third-party product Samba, can use the NTLM protocol to authenticate with Active Directory.

17. Certificate-based authentication
UNIX clients can use certificate-based authentication to access Web sites protected by Secure Sockets Layer (SSL) or Transport Layer Security (TLS). Certificate- based authentication requires a certification authority (CA) for certificate distribution. For the certificate to be recognized and the user to be authenticated, both the UNIX client and the Web server must trust the issuing CA.

18. Clear-text authentication
UNIX clients that use TCP/IP-based applications (including Telnet, File Transfer Protocol [FTP], and Hypertext Transfer Protocol [HTTP]) can use clear-text authentication to authenticate users against Active Directory. Because clear-text authentication is vulnerable to interception by an attacker, it is important to secure the authentication. You can secure clear-text authentication by implementing either SSL encryption (for protocols that are SSL aware, such as HTTP) or Internet Protocol Security (IPSec).

19. Securing SMB-based File Access
To Secure SMB-based File Access:
Use NTLM authentication to protect passwords
Create OUs for UNIX users
If using clear-text authentication, encrypt with IPSec

20. SMB client software allows UNIX-based computers to connect to resources stored on Windows 2000-based computers. SMB client software uses either clear-text authentication or the NTLM protocol to authenticate with Windows 2000.

21. When designing secure resource access between UNIX-based computers running SMB clients and Windows 2000-based resources, use the following guidelines:
Use NTLM authentication to protect passwords. For example, Samba version and later support NTLM authentication. Earlier versions of Samba require clear-text authentication.
Create user accounts in Active Directory for each UNIX user and place the user accounts in a separate organizational unit (OU) so that the account management can be delegated.
If using clear-text authentication, encrypt with IPSec. Clear-text authentication is set by enabling the Send unencrypted password to connect to third-party SMB servers Group Policy setting. This setting is found in Group Policy in Computer Configuration \Windows Settings\Security Settings \Local Policies\Security Options.

22. Securing NFS-based File Access
Mapping
Permissions C
NFS
UNIX User Account
Active Directory User Account
FileA
FileB
To Secure NFS-based File Access:
Associate UNIX accounts to Active Directory accounts
Use Active Directory accounts to set permissions
NTFS Volume

23. Note: If Windows 2000-based clients require access to UNIX-based NFS resources, install either Client for NFS or Gateway for NFS on the Windows 2000-based client. Use Gateway for NFS only for clients that infrequently access NFS resources.

24. Almost all UNIX-based operating systems include server and client software for NFS. Windows 2000 does not support an NFS client or server by default. However, Services for UNIX allows UNIX-based NFS clients to access data on Windows 2000-based servers by using Server for NFS.

25. To access Windows 2000-based resources, a UNIX NFS client first authenticates with a NIS server. The authenticating NIS server allocates a User Identifier (UID) and Group Identifier (GID) to the UNIX NFS client. The UID and GID properties are then mapped to, or an association is created with, a corresponding user account in Active Directory. The UNIX user account is assigned the SID of a user account and group account, thereby enabling the UNIX client to access Windows based resources.

26. When designing secure resource access between UNIX- based computers running NFS client software and Windows 2000-based resources, use the following guidelines:
Determine the UNIX UIDs and GIDs that must be mapped to Windows 2000 user and group accounts. Any UNIX UIDs or GIDs not included in name mapping will be unable to access NFS resources on the Windows based NFS server.
Set permissions on NFS resources by using the mapped user and group accounts.

27. When designing secure resource access between UNIX-based computers running NFS client software and Windows 2000-based resources, use the following guidelines.
Determine the UNIX UIDs and GIDs that must be mapped to Windows 2000 user and group accounts. Any UNIX UIDs or GIDs not included in name mapping will be unable to access NFS resources on the Windows 2000-based NFS server.
Set permissions on NFS resources by using the mapped user and group accounts.
Note: If Windows 2000-based clients require access to UNIX-based NFS resources, install either Client for NFS or Gateway for NFS on the Windows 2000-based client. Use Gateway for NFS only for clients that infrequently access NFS resources

28. Securing TCP/IP-based Applications
FTP
Use for non-sensitive data
Secure data by using IPSec
HTTP
Secure data by using SSL encryption
Secure passwords by using SSL encryption
Use certificate-based authentication
Telnet
Secure authentication by using IPSec

29. Windows 2000 includes several TCP/IP-based applications that UNIX clients can use to access resources on a Windows 2000 network or to manage a Windows 2000 network. Most of these applications use clear-text authentication and require encryption to ensure security.

30. Accessing Data Using FTP
Windows 2000 provides FTP client and server software. If UNIX clients are using FTP to access data on a Windows 2000-based server, use the following guidelines:
Use FTP servers only for the storage of non-sensitive data, and configure the server to allow only anonymous access. Requiring anonymous access prevents Active Directory credentials from being transmitted on the network in clear text.
If sensitive data must be accessible on an FTP server, use IPSec to encrypt data as it is transmitted from the FTP server to the UNIX FTP clients.

31. Accessing Data Using HTTP
UNIX-based computers can use Web browsers, which use HTTP, to access data stored on a Windows 2000-based computer running Internet Information Services (IIS). IIS allows data to be secured by using NTFS file system permissions so that only authorized users can access the data. If UNIX clients are using the HTTP protocol to access a Web site on a Windows 2000-based computer, use the following guidelines:
Encrypt classified data by configuring the IIS server to implement SSL encryption.
If authenticated access is required to the Web site, implement basic authentication in IIS, and use SSL to encrypt the clear-text passwords. Basic authentication allows UNIX Web browsers to authenticate with Active Directory.
For additional security, use certificate-based user authentication for the Web site.
Note: HTTP can be used as an alternative to FTP for accessing file resources. HTTP protected with SSL encryption requires less configuration than FTP protected with IPSec encryption.

32. Managing the Network Using Telnet
UNIX clients can run command-line utilities from a Telnet client connected to a Windows 2000-based Telnet server. Telnet requires authenticated access, but the authentication, by default, is passed in clear text. The clear-text authentication and data transferred between the client and server are vulnerable to interception by an attacker.

33. If UNIX clients require the ability to manage a Windows based server by using Telnet, consider encrypting all Telnet protocol transmissions by using IPSec. IPSec encryption will ensure that all authentication data and transmitted data is protected against interception.
Note: A Windows 2000-based Telnet server provides NTLM protocol support for authentication. NTLM will protect user credentials, but does not encrypt the actual data transmitted. UNIX-based Telnet clients do not support NTLM authentication.

34. Providing Secure Network Access to NetWare Clients
Introducing Services for NetWare Interoperability
Authenticating NetWare Clients
Securing Access to NetWare Resources

35. Integrating a Windows 2000 network with a NetWare network involves establishing connectivity and authentication both to and from each network. To connect Windows-based clients to a NetWare network, Windows 2000 provides two services, Gateway Service for NetWare and Client Service for NetWare. These two services allow Windows-based client computers to access NetWare file, print, and directory services that are located on NetWare bindery-based servers or Novell Directory Services (NDS)-based servers. To allow NetWare clients to access a Windows network, use Services for NetWare. Services for NetWare allows NetWare clients to access a Windows based server as if it were a NetWare server.

36. In this lesson you will learn about the following topics:
Introducing Services for NetWare interoperability
Authenticating NetWare clients
Securing access to NetWare resources

37. Introducing Services for NetWare Interoperability
NetWare Client
NetWare File
Server
IPX Network
Windows 2000
NetWare Gateway
NetWare Print
Server
IP Network
NWLink Protocol
Client Services for NetWare
Gateway Services for NetWare
Services for NetWare
Windows 2000–based Clients

38. Microsoft offers three software services-Gateway Service for NetWare, Client Service for NetWare, and Services for NetWare-that provide interoperability between Windows 2000-based computers and NetWare clients and servers.

39. NWLink Protocol
NetWare servers use Novell's Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX) protocol to communicate. The NWLink/IPX/SPX/NetBIOS Compatible Transport Protocol (NWLink) is the protocol that Windows 2000-based computers use to communicate with NetWare servers. NWLink is included with Windows 2000.

40. Client Service for NetWare
Client Service for NetWare is a Windows-based network client that allows access to NetWare resources. Client Service for NetWare is installed on individual Windows Professional-based clients and gives each client direct access to NetWare file, print, and directory services.

41. Gateway Service for NetWare
Gateway Service for NetWare is server-based software that provides a single point, or gateway, through which multiple Windows-based clients can access NetWare resources by using a single authenticated account on the NetWare server. Because the gateway provides a single access point to NetWare services, you do not need to install and maintain NetWare client software (such as the Client Service for NetWare) on each of your workstations. Gateway Service for NetWare also supports direct access to NetWare services from the computer providing the gateway, in the same way that Client Service for NetWare supports direct access from the client computer.

42. Services for NetWare
Services for NetWare is an add-on product for Windows that provides several utilities that help integrate Novell NetWare networks and Windows 2000 networks. Services for NetWare includes the following utilities.
Microsoft Directory Synchronization Services (MSDSS).
Microsoft File Migration Utility.
File and Print Services for NetWare.

43. Microsoft Directory Synchronization Services (MSDSS)
Provides two-way synchronization of directory information stored in Active Directory and NDS. Directory synchronization helps to reduce costs and simplifies network management because it eliminates the need to replace existing directories or manage separate directories. MSDSS can also synchronize account information with a Novell NetWare server using bindery services.

44. Microsoft File Migration Utility
Enables the migration of files from NetWare file and print servers to a computer running Windows Server, while preserving directory structures and security permissions.

45. File and Print Services for NetWare
Enables a computer running Windows 2000 to provide file and print services to NetWare computers. The Windows 2000-based server appears as any other NetWare server to the NetWare clients, and the clients can access volumes, files, and printers through the server. No changes or additions to the NetWare client software are necessary.

46. Authenticating NetWare Clients
Authenticating Using Gateway Service for NetWare
Uses a single user account
Gateway account must be a member of NTGATEWAY group
Permissions assigned to gateway user account or NTGATEWAY group
Authenticating Using Client Service for NetWare
Uses multiple accounts
MSDSS synchronizes multiple accounts
Authenticating Using File and Print Services for NetWare

47. Gateway Service for NetWare and Client Service for NetWare use authentication to allow Windows based computers access to NetWare resources. File and Print Services for NetWare uses authentication to allow NetWare clients to access Windows 2000-based resources.

48. Authenticating Using Gateway Service for NetWare
When using Gateway Service for NetWare, all user access to NetWare servers through the gateway is defined by a single user account that the gateway uses to manage all access to the NetWare server. The gateway service account must be in the NTGATEWAY group on the NetWare network to allow the gateway account to authenticate. Therefore, it is necessary to create accounts and groups to control access rights on the NetWare network. Accounts are required on the Windows 2000-based server for the clients accessing the Windows share and on the NetWare server to access resources.
All Windows-based clients will use the permissions assigned to the gateway accounts or to the NTGATEWAY group to access NetWare resources. For example, if multiple Gateway Service for NetWare servers are configured to access a NetWare server, apply permissions to the individual gateway accounts if different levels of access are required. Apply the permission to the NTGATEWAY group if all Gateway Service for NetWare servers require the same level of permission.

49. In many interoperability environments, the NetWare accounts will have supervisor privileges set on the NetWare server, which can pose a security risk if the account name and password are compromised. Always assign the minimum permissions and privileges to meet the access requirements that your organization requires. Always use the strongest password possible for the gateway account.
Note: The services that Microsoft provides require NWLink for NetWare connectivity. Later versions of NetWare support both NWLink and TCP/IP.

50. Authenticating Using Client Service for NetWare
When using Client Service for NetWare, it is necessary to create accounts and groups to control access rights on the NetWare network. Accounts on the NetWare server are required to allow Windows 2000-based clients access to resources.
If a large number of accounts must be maintained on both NetWare and Windows networks, it is advisable to install Microsoft Directory Synchronization Services (MSDSS), included with Services for NetWare 5.x. MSDSS enables Active Directory synchronization with NDS and NetWare 3.x binderies.

51. Authenticating Using File and Print Services for NetWare
A Window 2000-based server running File and Print Services for NetWare will emulate a NetWare 3.12 server to authenticate the NetWare client. The credentials that the client presents are authenticated against Active Directory.

52. Securing Access to NetWare Resources
Security Risks of Using the NWLink Protocol
Security Risks of Using Client Service for NetWare
Security Risks of Using Gateway Service for NetWare
Security Risks of Using Services for NetWare

53. Most NetWare servers use IPX/SPX as the underlying transport services in much the same way as IP, TCP, and User Datagram Protocol (UDP) are used in a TCP/IP- based network. Services that NetWare servers offer, such as file and print services, use NetWare Core Protocol (NCP) to support client connectivity. Gateway Service for NetWare and Client Service for NetWare provide the required protocols to support user authentication and administration in a mixed TCP/IP- based and IPX/SPX-based network.

54. Security Risks of Using the NWLink Protocol
Windows 2000 supports IPX/SPX for the transfer of data between the Windows and NetWare environments. The IPX/SPX-based network does not support the same security options available to the IP environment. Minimizing the number of protocols, and the extent to which the protocols are routed in your network, will reduce the risk of malicious attacks or of data being compromised.
When designing an environment to maintain high security for data transfers, remember that NetWare servers that use IPX/SPX indicate their availability over the network by using the Service Advertising Protocol (SAP), which can provide information for attackers.

55. Security Risks of Using Client Service for NetWare
When using Client Service for NetWare, each client requires a unique logon identity with permissions set at group or user level. Multiple accounts may be required to be synchronized between the Windows and NetWare environments. This imposes additional administration, which could lead to potential security lapses.

56. Security Risks of Using Gateway Service for NetWare
Using a single gateway account for Windows-based users to access NetWare resources provides sufficient security capability. Multiple clients use the same authenticated connection to the NetWare servers, which prohibits the use of user-level permissions.

57. Security Risks of Using Services for NetWare
NetWare clients can access resources on Windows based servers that are running File and Print Services for NetWare. To authenticate the NetWare client, File and Print Services allows a Windows based server to emulate a NetWare 3.12 server. NetWare clients that log on to multiple NetWare 3.12 servers provide credentials each time they initially attach to a server, and may store these credentials in clear text. A NetWare client authenticating against a Windows based server may therefore store Active Directory accounts and passwords in clear text, posing a security risk.

58. Providing Secure Network Access to Macintosh Clients
Interoperating with Macintosh Clients
Authenticating Macintosh Users
Providing Secure Access to Macintosh File and Print Resources

59. AppleTalk network integration is a component of Windows 2000 that combines several services to provide secure interconnectivity between Windows networks and Apple Macintosh clients. User authentication can be Macintosh based, or extended to support Windows authentication. Apple Talk network integration also provides file and print services.

60. In this lesson you will learn about the following topics:
Interoperating with Macintosh clients.
Authenticating Macintosh users.
Providing secure access to Macintosh file and print resources.

61. Interoperating with Macintosh Clients
AppleTalk Network Integration Services Include
File Services for Macintosh
Print Services for Macintosh
AppleTalk protocol
Supported Protocols
TCP/IP
AppleTalk Phase 2 protocol

62. You can use AppleTalk network integration services to create Macintosh-accessible volumes on a Windows based server that both Windows 2000-based clients and Macintosh clients can access. The three components of AppleTalk network integration are:
File Services for Macintosh
Print Services for Macintosh
AppleTalk protocol
Note: File Services for Macintosh and Print Services for Macintosh were formerly known collectively as Services for Macintosh.

63. File and Print Services
File Services for Macintosh is an AppleTalk network integration service that enables Macintosh clients and Microsoft clients to share files on a computer running Windows 2000 Server. Print Services for Macintosh enables Macintosh clients to send and spool documents to printers that are attached to a computer running Windows 2000 Server. Print Services for Macintosh also enables Macintosh and Windows clients to send documents to printers anywhere on an AppleTalk network.

64. Supported Protocols
TCP/IP or the AppleTalk Phase 2 protocol can be used to provide communication between File Services for Macintosh, Print Services for Macintosh, and the Macintosh network clients. A Windows based server can support both TCP/IP and AppleTalk protocols simultaneously. If File Services for Macintosh is made available over TCP/IP networks, it can be run on a network without using the AppleTalk protocol. File Services for Macintosh works with either AppleTalk or TCP/IP, but when both are installed on the client and the server, the Macintosh client attempts to start a connection by using TCP/IP first.
Note: To use Apple Filing Protocol (AFP) over TCP/IP networks, AppleShare client version 3.7 or later must be installed on the Macintosh client.

65. Authenticating Macintosh Users
Clear-text Password Authentication
Guest users: for data that is accessible anonymously
Users with clear-text passwords: do not use with sensitive domain user accounts
Encrypted Password Authentication
Apple Standard Encryption
Microsoft User Authentication Module (recommended)

66. Authenticating Macintosh Users
AppleTalk network integration services support several methods of encryption and user authentication to ensure network security.

67. Clear-text Password Authentication
Macintosh clients, by default, are configured to use simple non-encrypted passwords when accessing resources on a Windows 2000 network. Consider using non-encrypted password authentication only for data suitable for anonymous access.
You can configure a Windows 2000 network to authenticate Macintosh users as:
Guest users
Users with clear-text passwords

68. Guest users
With File Services for Macintosh, you can set up guest user accounts that allow users who do not have domain or workgroup accounts to log on to the server when using a Macintosh client. If the guest logon option is enabled, no password is required and all Macintosh clients will be permitted to access resources defined for the guest account. Use guest user authentication only for low-security configurations in which you will not audit or set permissions on server data.

69. Users with clear-text passwords
Clear-text password protection is part of the AppleShare client or Macintosh System 7 (or later) operating system software installed on Macintosh computers.

70. Encrypted Password Authentication
File Services for Macintosh permits the following authentication encryption methods that can be specified for Macintosh clients:
Apple Standard Encryption. Passwords are up to eight characters long. Although the passwords are encrypted, their short length makes them vulnerable to attack.
Microsoft User Authentication Module (MS-UAM). Passwords are up to 14 characters long. This method requires that AppleShare client version 3.8 be installed. MS-UAM is the recommended authentication method.
AppleTalk network integration services does not support Kerberos- based authentication.
Note: If the Windows 2000-based server permits clear-text passwords in addition to encrypted passwords, the Macintosh client will automatically use the encrypted authentication method.

71. Providing Secure Access to Macintosh File and Print Resources
Security for Files
Volume passwords can protect files on Windows based computers
Permissions based on user account and primary group
Macintosh Printing
No support for authentication
No user-level security

72. A computer running Windows 2000 Server with File Services for Macintosh can store files so that users of both the Windows-based and Macintosh computers can gain access.

73. Security for Files
File Services for Macintosh allows an optional extra level of security for file access through the use of Macintosh-accessible volume passwords. Volume passwords provide security similar to Windows share- level security. A volume password is a case-sensitive password that you can assign to a Macintosh- accessible volume during creation of the volume. To access the volume, a Macintosh user must type the volume password in addition to the user logon password. Permissions are based on the user account and the user's primary group.
Note: Windows 2000 users accessing data protected by volume passwords do not need to know the volume password to gain access to the resource.

74. Security Implications for Printing
Macintosh networking does not support security for printers because AppleTalk has no mechanism to authenticate a printing client. There is no user-level security for Macintosh printers.

75. Securing Network Services in a Heterogeneous Network
Assessing Risks Associated with DHCP
Assessing Risks Associated with DNS
Assessing Risks Associated with SNMP

76. Providing non-Microsoft clients access to a Windows network can introduce risks to network services, including interruptions to network services and clients, unauthorized access to data, and security problems that an attacker might exploit. Common network services that are at risk include Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), and Simple Network Management Protocol (SNMP).

77. In this lesson you will learn about the following topics:
Assessing risks associated with DHCP
Assessing risks associated with DNS
Assessing risks associated with SNMP

78. Assessing Risks Associated with DHCP
Unauthorized DHCP Servers Disrupting Service
Incorrect Client Configuration
Securing Windows 2000–based DHCP Servers
Authorized by Active Directory
Securing Non–Windows 2000–based DHCP Servers
Monitor IP addresses
Reserve DHCP IP addresses

79. Assessing Risks Associated with DHCP
DHCP is used to automatically assign IP address information to TCP/IP clients on the network. Windows includes a DHCP service that can be used to deploy IP address information. Third-party DHCP servers may also be used for the assignment of IP configuration. DHCP services are at risk from unauthorized DHCP servers gaining access to the network, and from unauthorized clients gaining access to the network with a DHCP-assigned IP address.

80. Securing Windows 2000-based DHCP Servers
Before a Windows 2000-based DHCP server can assign IP address information to DHCP clients, it must be authorized in Active Directory. Authorization prevents users from configuring Windows 2000-based DHCP servers without permission from domain administrators.

81. Securing Windows 2000-based DHCP Servers…
Adding a Windows 2000-based DHCP server to the DNS Update Proxy group can introduce a security risk. The DNS Update Proxy group allows other computers to take ownership of resource records registered by a DHCP server. Do not make the DHCP server a member of the DNS Update Proxy group if the DHCP server is a domain controller. Doing so will give any user or computer full control of the DNS records corresponding to the domain controllers, unless the corresponding object's discretionary access control list (DACL) is modified. Full control of these records can result in the DHCP server overwriting static DNS resource records for a non-Microsoft host.

82. Securing Non-Windows 2000-based DHCP Servers
Although authorization can be used to prevent unauthorized Windows 2000-based DHCP servers from issuing unauthorized IP addresses, authorization cannot be applied to third-party DHCP servers, or to computers running the DHCP service from Microsoft Windows NT® version 3.51 or Microsoft Windows NT version 4.0.

83. If your organization is using DHCP servers other than the DHCP server in Windows 2000, the only way to prevent unauthorized DHCP servers from operating on the network is to monitor for unauthorized IP address assignments and to physically shut down these unauthorized DHCP servers.
Tip: Use the ipconfig/all command to determine the IP address of the DHCP server from which the client computer's IP address was received.

84. Where stringent security requirements are required, you can create DHCP reservations for all IP addresses included in the DHCP scope. DHCP reservations based on the media access control (MAC) address of the requesting network card can reduce the risk of unauthorized computers being allocated valid addresses on the network.

85. Assessing Risks Associated with DNS
Risk: Unauthorized Overwrite of DNS Resource Records
Securing Windows 2000 DNS Server Service
Securing BIND DNS Services

86. Assessing Risks Associated with DNS
Active Directory uses DNS as a location service to resolve user-friendly names to other information about resources, such as IP addresses. Active Directory requires that a DNS server support SRV (Service) resource records. DNS services are at risk on a network from other hosts that may overwrite an existing DNS resource record. When deploying Active Directory in a network environment that contains non-Microsoft operating systems, your choices for DNS services include Windows 2000 DNS Server service and Berkeley Internet Name Domain (BIND) DNS.

87. Securing Windows 2000-based DNS Servers
Windows 2000 DNS Server service is best secured by implementing Active Directory integrated zones. By storing the DNS zone data in Active Directory, each resource record can be protected by a DACL that prevents other hosts from overwriting an existing DNS resource record.

88. If secure dynamic updates are enabled, only members of the Authenticated Users group are assigned permissions to update or create DNS resource records stored in Active Directory integrated zones. Because non-Microsoft clients do not have computer accounts, they cannot directly perform secure dynamic updates. To register DNS resource records for non-Microsoft clients in Active Directory integrated zones, you can:
Assign the non-Microsoft clients IP addresses from a Windows based DHCP server. The Windows 2000-based DHCP server can be configured to perform the dynamic updates on behalf of the non- Microsoft clients.
Manually create all necessary DNS resource records as static DNS resource records.
Note: Microsoft operating systems previous to Windows 2000 do not support dynamic updates and will experience the same issues as non-Microsoft clients.

89. Securing BIND DNS Services
Active Directory does not require that a Windows based DNS server provide all DNS services. BIND DNS servers can be used if they support SRV resource records as described in RFC It is also recommended that the BIND DNS server support the DNS dynamic update protocol to reduce manual administration of DNS resource records.
Note: BIND DNS meets the minimum DNS requirements for Active Directory by supporting SRV resource records. BIND and later versions provide support for dynamic updates, incremental zone transfers, and change notification.

90. When designing security for a BIND DNS server, use the following guidelines:
BIND DNS servers can host only primary or secondary DNS zones. There is no support for Active Directory integrated zones.
BIND DNS servers can only restrict updates to specific IP addresses. Restricting updates is done by configuring the allow-update option in the named.conf configuration file. However, restricting updates will not prevent another approved IP address from overwriting an existing DNS resource record.
Restrict DNS dynamic updates to domain controllers and DHCP servers in the allow-update option in the named.conf configuration file.

91. Assessing Risks Associated with SNMP
SNMP Agents
Clear-text Information
Status
SNMP Management Station
Windows 2000–based Computer
Configure SNMP Communities as Read Only
Change the Public Community Name
Restrict SNMP Management Stations
Use IPSec to Encrypt SNMP Traffic
Router
Hub

92. SNMP provides the ability to monitor and communicate status information for Windows 2000-based computers and most network hardware devices. SNMP uses a distributed architecture consisting of management systems and agents. The SNMP management systems receive SNMP status messages and trap messages sent from SNMP agents. Risks to SNMP services include unauthorized access to SNMP systems, and the interception of status and trap messages.

93. SNMP offers a limited form of security in that the SNMP agents can be logically grouped into communities. The SNMP agents can be configured to send status messages and trap messages to SNMP management stations that belong to the same community. Communities can be defined to allow one of the following rights for SNMP management systems: Notify, Read Only, Read Write, Read Create, or No Access. Additionally, SNMP agents can be configured to send SNMP messages only to a preconfigured SNMP management station. This configuration prevents unauthorized SNMP management stations from requesting data from SNMP agents.

94. The SNMP protocol does not encrypt any of the status messages or trap messages that are sent from the SNMP agents to the SNMP management systems. Captured SNMP data could provide an attacker with critical information concerning your network.

95. To improve security when configuring SNMP, use the following guidelines:
If SNMP management stations will not require write access to the SNMP agents, ensure that community names are configured to provide read-only access to the SNMP management stations.
Change the default community name from public because this is a security risk. Attackers will always attempt SNMP requests against the public community as a first step.
Configure SNMP agents to accept SNMP packets only from specified SNMP management stations. By default, the SNMP agent will accept SNMP packets from any host on the network.
Define an IPSec policy to encrypt all data between the SNMP management stations and SNMP agents for SNMP and SNMP trap transmissions. This will require that all SNMP management stations and all SNMP-enabled devices support IPSec.

96. Monitoring for Security Breaches
Authorized Network Monitor Usage
Captures network traffic
Can reveal security breaches
Unauthorized Network Sniffer Usage
May capture clear-text authentication
Can include Network Monitor or other network sniffer tools

97. Analysis of network information can alert you to security breaches or weaknesses. Tools that monitor network traffic are sometimes called network sniffers. Using Network Monitor (included with Windows Server) and other network monitoring tools can lead to the capture of unencrypted data transmissions as they cross the network.

98. Authorized Network Monitor Usage
Network Monitor can be used to determine security weaknesses in data transmissions by periodically inspecting network traffic. In low-security or medium- security environments, Network Monitor can be configured by using input filters to capture only the information required to analyze an attack or breach of security. For example, Network Monitor could capture all Telnet traffic. You would then analyze the data to determine whether clear-text authentication is used when accessing a Telnet server. In high-security environments, Network Monitor can be configured to capture all traffic. Capturing all network traffic ensures that no protocol is missed in a network capture.

99. Unauthorized Network Sniffer Usage
Network sniffers may capture and transmit sensitive information as they collect data on the network. Heterogeneous clients on a network often revert to using clear-text for authentication. An attacker using Network Monitor or other network sniffers could intercept the clear-text information as the tools collect network information. Network credentials captured by network sniffers can be used to gain access to the network. Ensure that tools are used to detect network sniffers being used on the network.

100. Lab A: Securing Telnet Transmissions

101. Review Providing Secure Network Access to UNIX Clients
Providing Secure Network Access to NetWare Clients
Providing Secure Network Access to Macintosh Clients
Securing Network Services in a Heterogeneous Network
Monitoring for Security Breaches