1 / 47

Designing Microsoft Windows 2000 Services Security

Designing Microsoft Windows 2000 Services Security. Designing DNS Security Designing DHCP Security Designing RIS Security Designing SNMP Security Designing Terminal Services Security. Designing DNS Security. Assessing security risks for the DNS service Overview of DNS service

jennifer-stone
Download Presentation

Designing Microsoft Windows 2000 Services Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Designing Microsoft Windows 2000 Services Security • Designing DNS Security • Designing DHCP Security • Designing RIS Security • Designing SNMP Security • Designing Terminal Services Security

  2. Designing DNS Security • Assessing security risks for the DNS service • Overview of DNS service • Risks of deploying the DNS service • Determining network services with SRV resource records • Securing dynamic updates • Restricting zone transfers • Implementing separate external DNS servers • Restricting membership in the DNS Admins group

  3. Risks of Deploying the DNS Service • Client computers can overwrite existing DNS resource records and hijack sessions. • Attackers can create a secondary DNS zone and obtain a read-only copy of the DNS zone data. • DNS services available on the Internet can expose the internal IP addressing scheme of the internal network.

  4. SRV Resource Record Format • _ldap._tcp.microsoft.com. 600 SRV 0 100 389 dc1.microsoft.com • The advertised service (_ldap) • The transport protocol (_tcp) • The domain (microsoft.com) • The TTL (600) • SRV • The priority and weight (0 100) • The port that the service is listening on • Network host where the LDAP service resides (dc1.microsoft.com)

  5. Active Directory–Integrated Zones • Store their resource records within Active Directory instead of standard DNS text files • Limited to a single domain

  6. Active Directory–Integrated Zone Advantages • Fault tolerance of zone data • Reduction in replication topologies • Security on resource records

  7. Berkeley Internet Name Daemon (BIND) • BIND 8.x DNS can restrict dynamic updates to specific IP addresses. • BIND DNS cannot authenticate DNS updates using Active Directory authentication.

  8. Restricting Zone Transfers • Transfer zone data to secondary DNS servers. • Ensure that secondary DNS servers have current information. • Implement secondary DNS zones in multiple domains. • Restrict zone transfers to authorized DNS servers.

  9. Implementing Separate External DNS Servers

  10. Restricting Membership in the DNS Admins Group • The DNS Admins group can create new DNS zones and modify properties of the DNS server. • Only authorized user accounts should be members of the DNS Admins group. • Use Restricted Groups to restrict DNS Admins group membership.

  11. Making the Decision: Securing the DNS Service • Protect the internal address space. • Prevent the failure of a single DNS server from stopping dynamic DNS updates. • Prevent unauthorized DNS servers from hosting DNS zone data. • Prevent the registration of unauthorized resource records. • Prevent unauthorized membership in the DNS Admins group.

  12. Applying the Decision: Securing the DNS Service at Lucerne Publishing • Establish both internal and external DNS servers. • Configure secondary DNS servers for each child domain. • Restrict zone transfers to approved secondary DNS servers.

  13. Designing DHCP Security • Assessing the security risks of the Dynamic Host Configuration Protocol (DHCP) service • Security risk categories • Preventing unauthorized DHCP servers • Preventing DHCP servers from overwriting static IP addresses in DNS • Preventing unauthorized DHCP clients from leasing IP addresses

  14. Security Risk Categories • An unauthorized DHCP server assigning incorrect IP addressing information • The DHCP server overwriting static IP address information in DNS • Unauthorized DHCP clients leasing IP addresses on the network

  15. Preventing Unauthorized DHCP Servers • Active Directory–integrated DHCP servers must be authorized in Active Directory. • Only authorized Active Directory–integrated DHCP servers can issue IP addresses. • By default, only members of the Enterprise Admins universal group can authorize DHCP servers in Active Directory. • Non–Windows 2000 DHCP services can still be started on the network and could issue incorrect IP addresses.

  16. Preventing DHCP Servers from Overwriting Static IP Addresses in DNS • DNS behavior for down-level clients • Default DNS behavior for Windows 2000 clients • DNS resource record ownership in Active Directory–integrated zones

  17. Preventing Unauthorized DHCP Clients from Leasing IP Addresses • DHCP may introduce security weaknesses. • Any DHCP client can lease a valid IP address on the network. • Reserve all IP addresses in the scope to specific Media Access Control (MAC) addresses. • Consider applying static IP addresses rather than using IP address reservations.

  18. Making the Decision: Securing the DHCP Service • Prevent unauthorized DHCP servers on the network. • Protect domain controller (DC) related DNS resource records. • Ensure that authorized clients receive DHCP addresses. • Detect unauthorized non–Windows 2000 DHCP servers.

  19. Applying the Decision: Securing the DHCP Service at Lucerne Publishing • Move the DHCP services at the Caracas and Casablanca offices to member servers. • Clients upgraded to Windows 2000 should be able to take over the registration of DNS resource records. • DHCP servers should be made members of the DNSUpdateProxy group. • If DHCP services remain on DCs, overwrite the DC's DNS resource records or the static DNS resource records. • Configure DHCP servers to perform dynamic updates on behalf of all DNS clients that do not support dynamic updates.

  20. Designing RIS Security • Remote Installation Services (RIS) overview • Assessing security risks for remote installation

  21. Components of RIS

  22. Assessing Security Risks for Remote Installation • Authorizing RIS servers • Defining which RIS servers will respond to client requests • Restricting the creation of computer accounts • Ensuring proper security settings on the RIS image computer • Protecting data transmissions between RIS clients and RIS servers • Restricting which RIS images a user can load

  23. Restricting Which RIS Images a User Can Load

  24. Making the Decision: Designing RIS Security • Prevent deployment of unauthorized RIS servers. • Restrict RIS-installed computer accounts to a specific organizational unit (OU). • Restrict who can perform remote installations. • Restrict which images a user can load. • Maintain default security for RIS images. • Protect administrative permissions.

  25. Applying the Decision: If Lucerne Publishing Prestages Client Computers • Ensure that a member of the Enterprise Admins group authorizes all RIS servers in Active Directory. • Determine the GUIDs for each new computer and create the computer account in the RIS Computer OU. • Create a domain local group that has permissions to modify the attributes of the computer object. • Configure the RIS server so that it does not respond to requests from unknown clients.

  26. Applying the Decision: If Lucerne Publishing Allows Users to Create Computer Accounts • Ensure that a member of the Enterprise Admins group authorizes all RIS servers in Active Directory. • Configure the RIS server to create the computer accounts in the RIS Computers OU. • Delegate all authorized users with the ability to Join A Computer To The Domain at the RIS Computers OU. • Modify the discretionary access control list (DACL) for the Templates folder of the remote installation package to allow only users from the domain to download the image.

  27. Designing SNMP Security • Simple Network Management Protocol (SNMP) overview • Assessing the security risks of SNMP

  28. SNMP Functions • Monitor network performance • Detect network faults or unauthorized access • Configure network devices • Audit network usage

  29. SNMP Participants • SNMP management stations • SNMP agents

  30. SNMP Design Considerations • Configuration of SNMP communities • Configuration of approved SNMP management stations • Interception of SNMP status messages and SNMP trap messages

  31. Restricting Management to Specific SNMP Communities • The SNMP communities • Define a collection of SNMP agents • Do not have to map to domains within Active Directory • Should map to areas of management within the network

  32. Community Rights • None or Notify • Read Only • Read Create or Read Write

  33. Restricting Management to Specific SNMP Management Stations • Configure each SNMP agent to respond only to specific SNMP management stations. • Configure SNMP agents to send messages only to a preconfigured management station.

  34. Protecting SNMP Messages from Interception • SNMP status messages and SNMP trap messages are sent in clear text across the network. • Configure IPSec to require that SNMP status messages and trap messages be encrypted. • All SNMP agents must support the use of IPSec.

  35. Making the Decision: Securing the SNMP Service • Prevent SNMP management stations from modifying configuration by using SNMP SET commands. • Prevent unauthorized SNMP management stations from managing SNMP agents. • Track unauthorized management attempts. • Protect SNMP messages from interception.

  36. Applying the Decision: Securing the SNMP Service at Lucerne Publishing • Map separate community names to domains within the lucernepublishing.tld forest. • Configure all SNMP communities as Read Only. • Restrict management to occur only within the domain. • Detect unauthorized SNMP management attempts.

  37. Designing Terminal Services Security • Terminal Services overview • Assessing the security risks of Terminal Services

  38. Terminal Services Overview • Terminal Services allows clients to run Windows 2000–compatible applications on a terminal server without loading Windows 2000 at the client. • The terminal server hosts all client data processing, application execution, and data storage. • The client sends only keyboard and mouse input to Terminal Services. • The terminal server performs all processing and returns only display information to the client. • Change the shell application from the default of Explorer.exe to limit Terminal Services sessions to a single application.

  39. Restricting Remote Administration • Remote Administration Mode • Provides remote administration of a server • Supports a maximum of two simultaneous connections • Only members of the Administrators group can connect to the terminal server

  40. Restricting Access to the Local File System • Clients see the file system on the terminal server as their local file system. • Restrict client access to specific areas of the file system. • Use NT file system (NTFS) to restrict access to specific folders on the server. • Clients also share any services related to the computer.

  41. Determining Where to Deploy Terminal Services • Do not deploy Terminal Services using Application Server Mode on a DC. • This would allow Terminal Services users to log on locally to all DCs. • Install Terminal Services on member servers so that excess rights are not granted on DCs.

  42. Implementing Individual User Security • By default, security is based on membership in the Terminal Server Users group. • Any user logged on at a terminal server is made a member of the Terminal Server Users group. • Use the incremental security template Notssid.inf to remove the Terminal Server Users group from all DACLs on the file system. • Remove this group to ensure that access to the file system is based on user accounts and group memberships. • Place all terminal servers in a common OU and import the Notssid.inf security template into the Group Policy object for that OU.

  43. Securing Terminal Services Transmissions • Low encryption • Medium encryption • High encryption

  44. Planning for Loss of Strong Authentication Methods • Terminal Services does not support the use of two-factor authentication such as smart cards and the Kerberos v5 protocol. • Smart cards and the Kerberos v5 protocol cannot be used to restrict accounts.

  45. Making the Decision: Securing Terminal Services • Limit access to administrators of the network. • Restrict access to the local file system. • Prevent users from being assigned excess user rights. • Determine if a user is connected to the network using Terminal Services. • Restrict access to a single application. • Protect data transmissions between the Terminal Services client and the terminal server. • Restrict access to Terminal Services.

  46. Applying the Decision: Securing Terminal Services for Lucerne Publishing • Terminal Services mode • Excess rights assignments • Terminal server encryption • Additional configuration

  47. Chapter Summary • Assessing the security risks of the DNS service • Assessing the security risks of the DHCP Service • RIS overview • Assessing the security risks of remote installation • SNMP overview • Assessing the security risks of SNMP • Terminal Services overview • Assessing the security risks of Terminal Services

More Related