From 69c9a82832fa9afbc881ae2b44b658910a6e7867 Mon Sep 17 00:00:00 2001 From: Eric Jenkins Date: Tue, 11 Aug 2020 13:06:42 -0400 Subject: [PATCH] added dns V1R15 (#697) squash/merge --- CHANGELOG.md | 1 + ...12_Server_DNS_STIG_V1R15_Manual-xccdf.log} | 0 ...12_Server_DNS_STIG_V1R15_Manual-xccdf.xml} | 223 +++++++++--------- ...dowsDnsServer-2012R2-1.15.org.default.xml} | 2 +- ...3.xml => WindowsDnsServer-2012R2-1.15.xml} | 17 +- 5 files changed, 129 insertions(+), 114 deletions(-) rename source/StigData/Archive/Windows.DNS/{U_Microsoft_Windows_2012_Server_DNS_V1R13_Manual-xccdf.log => U_Microsoft_Windows_2012_Server_DNS_STIG_V1R15_Manual-xccdf.log} (100%) rename source/StigData/Archive/Windows.DNS/{U_Microsoft_Windows_2012_Server_DNS_V1R13_Manual-xccdf.xml => U_Microsoft_Windows_2012_Server_DNS_STIG_V1R15_Manual-xccdf.xml} (97%) rename source/StigData/Processed/{WindowsDnsServer-2012R2-1.13.org.default.xml => WindowsDnsServer-2012R2-1.15.org.default.xml} (89%) rename source/StigData/Processed/{WindowsDnsServer-2012R2-1.13.xml => WindowsDnsServer-2012R2-1.15.xml} (98%) diff --git a/CHANGELOG.md b/CHANGELOG.md index c45b528a2..9c6f856ca 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,7 @@ ## [Unreleased] +* Update PowerSTIG to successfully parse/apply Microsoft Windows 2012 Server DNS - V1R15: [#696](https://github.com/microsoft/PowerStig/issues/696) * Update PowerSTIG to successfully parse/apply SQL Server 2016 Instance V1R10: [#704](https://github.com/microsoft/PowerStig/issues/704) * Update PowerSTIG to successfully parse/apply Mozilla Firefox - V4R29: [#698](https://github.com/microsoft/PowerStig/issues/698) * Update PowerSTIG to successfully parse/apply IIS 10.0 Site/Server V1R2 STIGs: [#699](https://github.com/microsoft/PowerStig/issues/699) diff --git a/source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_V1R13_Manual-xccdf.log b/source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_STIG_V1R15_Manual-xccdf.log similarity index 100% rename from source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_V1R13_Manual-xccdf.log rename to source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_STIG_V1R15_Manual-xccdf.log diff --git a/source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_V1R13_Manual-xccdf.xml b/source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_STIG_V1R15_Manual-xccdf.xml similarity index 97% rename from source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_V1R13_Manual-xccdf.xml rename to source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_STIG_V1R15_Manual-xccdf.xml index 462fbbf81..86de47359 100644 --- a/source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_V1R13_Manual-xccdf.xml +++ b/source/StigData/Archive/Windows.DNS/U_Microsoft_Windows_2012_Server_DNS_STIG_V1R15_Manual-xccdf.xml @@ -1,4 +1,4 @@ -acceptedMicrosoft Windows 2012 Server Domain Name System Security Technical Implementation GuideThe Microsoft Windows 2012 Server Domain Name System Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.DISASTIG.DOD.MILRelease: 13 Benchmark Date: 24 Jan 20201I - Mission Critical Classified<ProfileDescription></ProfileDescription>I - Mission Critical Public<ProfileDescription></ProfileDescription>I - Mission Critical Sensitive<ProfileDescription></ProfileDescription>II - Mission Support Classified<ProfileDescription></ProfileDescription>II - Mission Support Public<ProfileDescription></ProfileDescription>II - Mission Support Sensitive<ProfileDescription></ProfileDescription>III - Administrative Classified<ProfileDescription></ProfileDescription>III - Administrative Public<ProfileDescription></ProfileDescription>III - Administrative Sensitive<ProfileDescription></ProfileDescription>SRG-APP-000001-DNS-000115<GroupDescription></GroupDescription>WDNS-AC-000001The Windows 2012 DNS Server must restrict incoming dynamic update requests to known clients.<VulnDiscussion>Limiting the number of concurrent sessions reduces the risk of Denial of Service (DoS) on any system. +acceptedMicrosoft Windows 2012 Server Domain Name System Security Technical Implementation GuideThe Microsoft Windows 2012 Server Domain Name System Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.DISASTIG.DOD.MILRelease: 15 Benchmark Date: 24 Jul 20201I - Mission Critical Classified<ProfileDescription></ProfileDescription>I - Mission Critical Public<ProfileDescription></ProfileDescription>I - Mission Critical Sensitive<ProfileDescription></ProfileDescription>II - Mission Support Classified<ProfileDescription></ProfileDescription>II - Mission Support Public<ProfileDescription></ProfileDescription>II - Mission Support Sensitive<ProfileDescription></ProfileDescription>III - Administrative Classified<ProfileDescription></ProfileDescription>III - Administrative Public<ProfileDescription></ProfileDescription>III - Administrative Sensitive<ProfileDescription></ProfileDescription>SRG-APP-000001-DNS-000115<GroupDescription></GroupDescription>WDNS-AC-000001The Windows 2012 DNS Server must restrict incoming dynamic update requests to known clients.<VulnDiscussion>Limiting the number of concurrent sessions reduces the risk of Denial of Service (DoS) on any system. A DNS server's function requires it to be able to handle multiple sessions at a time so limiting concurrent sessions could potentially cause an impact to availability. Primary name servers need to be configured to limit the actual hosts from which they will accept dynamic updates and from which they will accept zone transfer requests, and all name servers should be configured to limit the hosts from/to which they receive/send zone transfers. Restricting sessions to known hosts will mitigate the DoS vulnerability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000054Log on to the DNS server using the Domain Admin or Enterprise Admin account. @@ -98,7 +98,7 @@ Click on the “Event Logging” tab. By default, all events are logged. Verify "Errors and warnings" or "All events" is selected. -If any option other than "Errors and warnings" or "All events" is selected, this is a finding.SRG-APP-000089-DNS-000005<GroupDescription></GroupDescription>WDNS-AU-000006The Windows 2012 DNS Server logging must be enabled to record events from all DNS server functions.<VulnDiscussion>DNS server performance can be affected when additional logging is enabled, however the enhanced DNS logging and diagnostics feature in Windows Server 2012 R2 is designed to have a very low impact on performance. Enhanced DNS logging and diagnostics in Windows Server 2012 R2 and later includes DNS Audit events and DNS Analytic events. DNS audit logs are enabled by default, and do not significantly affect DNS server performance. DNS analytical logs are not enabled by default and typically will only affect DNS server performance at very high DNS query rates. +If any option other than "Errors and warnings" or "All events" is selected, this is a finding.SRG-APP-000089-DNS-000005<GroupDescription></GroupDescription>WDNS-AU-000006The Windows 2012 DNS Server logging must be enabled to record events from all DNS server functions.<VulnDiscussion>DNS server performance can be affected when additional logging is enabled, however the enhanced DNS logging and diagnostics feature in Windows Server 2012 R2 is designed to have a very low impact on performance. Enhanced DNS logging and diagnostics in Windows Server 2012 R2 and later includes DNS Audit events and DNS Analytic events. DNS audit logs are enabled by default, and do not significantly affect DNS server performance. DNS analytical logs are not enabled by default and typically will only affect DNS server performance at very high DNS query rates. Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. The actual auditing is performed by the OS/NDM, but the configuration to trigger the auditing is controlled by the DNS server. @@ -113,17 +113,17 @@ Use the “Set-DnsServerDiagnostics” cmdlet to enable the required diagnostic Set-DnsServerDiagnostics -<diagnostic event> $true <enter> for the required diagnostic events. For example, to set EnableLoggingForLocalLookupEvent to true, enter the following at the command line: Set-DnsServerDiagnostics -EnableLoggingForLocalLookupEvent $true <enter> -Log on to the DNS server using the Domain Admin or Enterprise Admin account. +Log on to the DNS server using the Domain Admin or Enterprise Admin account. Open an elevated Windows PowerShell prompt on a DNS server using the Domain Admin or Enterprise Admin account. Use the “Get-DnsServerDiagnostics” cmdlet to view the status of individual diagnostic events. Verify following diagnostic events are set to "True": -Queries, Answers, Notifications, Update, QuestionTransactions, UnmatcheResponse, SendPackets, ReceivePackets, TcpPackets, UdpPackets, FullPackets, UseSystemEventLog -Also set to “True” should be: +Queries, Answers, Notifications, Update, QuestionTransactions, UnmatcheResponse, SendPackets, ReceivePackets, TcpPackets, UdpPackets, FullPackets, UseSystemEventLog +Also set to “True” should be: EnableLoggingForLocalLookupEvent -EnableLoggingForPluginDLLEvent +EnableLoggingForPluginDLLEvent EnableLoggingForRecursiveLookupEvent EnableLoggingForRemoteServerEvent EnableLoggingForRemoteServerEvent @@ -132,6 +132,8 @@ EnableLoggingForTombstoneEvent EnableLoggingForZoneDataWriteEvent EnableLoggingForZoneLoadingEvent +Note: The UseSystemEventLog does not have to be set to true if all other variables are logged per the requirement and it can be validated that the events are being logged to a different log file destination. + If all required diagnostic events are not set to "True", this is a finding. SRG-APP-000090-DNS-000005<GroupDescription></GroupDescription>WDNS-AU-000007The Windows 2012 DNS Server logging criteria must only be configured by the ISSM or individuals appointed by the ISSM.<VulnDiscussion>Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. The actual auditing is performed by the OS/NDM, but the configuration to trigger the auditing is controlled by the DNS server. @@ -155,12 +157,12 @@ Navigate to Local Computer Policy >> Computer Configuration >> Windo If any accounts or groups other than the following are granted the "Manage auditing and security log" user right, this is a finding: -Administrators +Administrators Auditors (if the site has an Auditors group that further limits this privilege.) -If an application requires this user right, this would not be a finding. -Vendor documentation must support the requirement for having the user right. -The requirement must be documented with the ISSO. +If an application requires this user right, this would not be a finding. +Vendor documentation must support the requirement for having the user right. +The requirement must be documented with the ISSO. The application account must meet requirements for application account passwords. Verify the permissions on the DNS logs. @@ -196,7 +198,7 @@ From the right pane, under the “SERVERS” section, right-click the DNS server From the displayed context menu, click the “DNS Manager” option. -Click on the “Event Logging” tab. +Click on the “Event Logging” tab. Select the "Errors and warnings" or "All events" option. @@ -235,13 +237,13 @@ If any option other than "Errors and warnings" or "All events" is selected, this For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. -Run “eventvwr.msc” at an elevated command prompt. +Run “eventvwr.msc” at an elevated command prompt. In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. Right-click on the DNS Server, point to View, and then click "Show Analytic and Debug Logs". -Right-click on Analytical and then click “Properties”. +Right-click on Analytical and then click “Properties”. Confirm the "Enable logging" check box is selected. @@ -253,7 +255,7 @@ The choice of digital signature algorithm will be based on recommended algorithm * RSA * Elliptic Curve DSA (ECDSA). -Of these three algorithms, RSA and DSA are more widely available and considered candidates of choice for DNSSEC. In terms of performance, both RSA and DSA have comparable signature generation speeds, but DSA is much slower for signature verification. RSA is the recommended algorithm as far as this guideline is concerned. +Of these three algorithms, RSA and DSA are more widely available and considered candidates of choice for DNSSEC. In terms of performance, both RSA and DSA have comparable signature generation speeds, but DSA is much slower for signature verification. RSA is the recommended algorithm as far as this guideline is concerned. RSA with SHA-1 is currently the only cryptographic algorithm mandated to be implemented with DNSSEC, although other algorithm suites (i.e. RSA/SHA-256, ECDSA) are also specified. @@ -265,7 +267,7 @@ Log on to the DNS server using the Domain Admin or Enterprise Admin account. Press Windows Key + R, execute dnsmgmt.msc. -On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones. +On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones. From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click “Sign the Zone”, either using approved saved parameters or approved custom parameters.Note: This requirement applies to any Windows DNS Server which host non-AD-integrated zones even if the DNS servers host AD-integrated zones, too. If the Windows DNS Server only hosts AD-integrated zones and does not host any file-based zones, this is not applicable. Validate this check from the Windows 2012 DNS server being configured/reviewed. @@ -318,7 +320,7 @@ From the right pane, under the SERVERS section, right-click the DNS server. From the displayed context menu, click the DNS Manager option. -Click on the Event Logging tab. +Click on the Event Logging tab. Select the "Errors and warnings" or "All events" option. @@ -350,7 +352,7 @@ Verify "Errors and warnings" or "All events" is selected. If any option other than "Errors and warnings" or "All events" is selected, this is a finding. For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. - + Run eventvwr.msc at an elevated command prompt. In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. @@ -454,7 +456,7 @@ Verify "Errors and warnings" or "All events" is selected. If any option other than "Errors and warnings" or "All events" is selected, this is a finding. For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. - + Run eventvwr.msc at an elevated command prompt. In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. @@ -506,7 +508,7 @@ Verify "Errors and warnings" or "All events" is selected. If any option other than "Errors and warnings" or "All events" is selected, this is a finding. For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. - + Run eventvwr.msc at an elevated command prompt. In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. @@ -535,7 +537,7 @@ Click on Apply. Click on OK. -For Windows 2012 R2 DNS Server, run eventvwr.msc at an elevated command prompt. +For Windows 2012 R2 DNS Server, run eventvwr.msc at an elevated command prompt. In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. @@ -558,7 +560,7 @@ Verify "Errors and warnings" or "All events" is selected. If any option other than "Errors and warnings" or "All events" is selected, this is a finding. For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. - + Run eventvwr.msc at an elevated command prompt. In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. @@ -587,7 +589,7 @@ Click on Apply. Click on OK. -For Windows 2012 R2 DNS Server, run eventvwr.msc at an elevated command prompt. +For Windows 2012 R2 DNS Server, run eventvwr.msc at an elevated command prompt. In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. @@ -610,8 +612,8 @@ Verify "Errors and warnings" or "All events" is selected. If any option other than "Errors and warnings" or "All events" is selected, this is a finding. For Windows 2012 R2 DNS Server, the Enhanced DNS logging and diagnostics in Windows Server 2012 R2 must also be enabled. - -Run eventvwr.msc at an elevated command prompt. + +Run eventvwr.msc at an elevated command prompt. In the Event viewer, navigate to the applications and Services Logs\Microsoft\Windows\DNS Server. @@ -621,7 +623,7 @@ Right-click Analytical and then click on Properties. Confirm the "Enable logging" check box is selected. -If the check box to enable analytic and debug logs is not enabled on a Windows 2012 R2 DNS server, this is a finding.SRG-APP-000125-DNS-000012<GroupDescription></GroupDescription>WDNS-AU-000016The Windows 2012 DNS Servers audit records must be backed up at least every seven days onto a different system or system component than the system or component being audited.<VulnDiscussion>Protection of log data includes assuring log data is not accidentally lost or deleted. Backing up audit records to a different system or onto separate media than the system being audited on a defined frequency helps to assure, in the event of a catastrophic system failure, the audit records will be retained. +If the check box to enable analytic and debug logs is not enabled on a Windows 2012 R2 DNS server, this is a finding.SRG-APP-000125-DNS-000012<GroupDescription></GroupDescription>WDNS-AU-000016The Windows 2012 DNS Servers audit records must be backed up at least every seven days onto a different system or system component than the system or component being audited.<VulnDiscussion>Protection of log data includes assuring log data is not accidentally lost or deleted. Backing up audit records to a different system or onto separate media than the system being audited on a defined frequency helps to assure, in the event of a catastrophic system failure, the audit records will be retained. This helps to ensure a compromise of the information system being audited does not also result in a compromise of the audit records. @@ -638,10 +640,10 @@ Press Windows Key + R, execute dnsmgmt.msc. On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones. -From the expanded list, click to select the zone. +From the expanded list, click to select the zone. Right-click on the zone, choose DNSSEC->Properties. - + On the ZSK tab, for DS signature validity period (hours), choose more than 48 and less than 168.Note: This check is Not applicable for Windows 2012 DNS Servers that only host Active Directory integrated zones or for Windows 2012 DNS servers on a Classified network. Log on to the DNS server using the Domain Admin or Enterprise Admin account. @@ -650,20 +652,20 @@ Press Windows Key + R, execute dnsmgmt.msc. On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones. -From the expanded list, click to select the zone. +From the expanded list, click to select the zone. -View the validity period for the DS Resource Record. +View the validity period for the DS Resource Record. If the validity period for the DS Resource Record for the child domain is less than two days (48 hours) or more than one week (168 hours), this is a finding.SRG-APP-000218-DNS-000027<GroupDescription></GroupDescription>WDNS-CM-000002The Windows DNS name servers for a zone must be geographically dispersed.<VulnDiscussion>In addition to network-based separation, authoritative name servers should be dispersed geographically as well. In other words, in addition to being located on different network segments, the authoritative name servers should not all be located within the same building. One approach that some organizations follow is to locate some authoritative name servers in their own premises and others in their ISPs' data centers or in partnering organizations. -A network administrator may choose to use a "hidden" master authoritative server and only have secondary servers visible on the network. A hidden master authoritative server is an authoritative DNS server whose IP address does not appear in the name server set for a zone. If the master authoritative name server is "hidden", a secondary authoritative name server may reside in the same building as the hidden master.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366For non-AD-integrated Windows DNS Servers, distribute secondary authoritative servers to be located in different buildings from the primary authoritative server. Windows DNS Servers that are Active Directory integrated must be located where required to meet the Active Directory services. +A network administrator may choose to use a "hidden" master authoritative server and only have secondary servers visible on the network. A hidden master authoritative server is an authoritative DNS server whose IP address does not appear in the name server set for a zone. If the master authoritative name server is "hidden", a secondary authoritative name server may reside in the same building as the hidden master.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366For non-AD-integrated Windows DNS Servers, distribute secondary authoritative servers to be located in different buildings from the primary authoritative server. Windows DNS Servers that are Active Directory integrated must be located where required to meet the Active Directory services. If all of the Windows DNS Servers are AD integrated, this check is Not Applicable. If any or all of the Windows DNS Servers are standalone and non-AD-integrated, verify with the System Administrator their geographic location. If any or all of the authoritative name servers are located in the same building as the master authoritative name server, and the master authoritative name server is not "hidden", this is a finding. -SRG-APP-000383-DNS-000047<GroupDescription></GroupDescription>WDNS-CM-000003The Windows 2012 DNS Server must prohibit recursion on authoritative name servers for which forwarders have not been configured for external queries.<VulnDiscussion>A potential vulnerability of DNS is that an attacker can poison a name server's cache by sending queries that will cause the server to obtain host-to-IP address mappings from bogus name servers that respond with incorrect information. Once a name server has been poisoned, legitimate clients may be directed to non-existent hosts (which constitutes a denial of service), or, worse, hosts that masquerade as legitimate ones to obtain sensitive data or passwords. +SRG-APP-000383-DNS-000047<GroupDescription></GroupDescription>WDNS-CM-000003The Windows 2012 DNS Server must prohibit recursion on authoritative name servers for which forwarders have not been configured for external queries.<VulnDiscussion>A potential vulnerability of DNS is that an attacker can poison a name server's cache by sending queries that will cause the server to obtain host-to-IP address mappings from bogus name servers that respond with incorrect information. Once a name server has been poisoned, legitimate clients may be directed to non-existent hosts (which constitutes a denial of service), or, worse, hosts that masquerade as legitimate ones to obtain sensitive data or passwords. To guard against poisoning, name servers authoritative for .mil domains should be separated functionally from name servers that resolve queries on behalf of internal clients. Organizations may achieve this separation by dedicating machines to each function or, if possible, by running two instances of the name server software on the same machine: one for the authoritative function and the other for the resolving function. In this design, each name server process may be bound to a different IP address or network interface to implement the required segregation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Log on to the DNS server using the Domain Admin or Enterprise Admin account. @@ -673,7 +675,7 @@ On the opened DNS Manager snap-in from the left pane, right-click on the server Click on the “Forwarders” tab. -If forwarders are not being used, click the “Advanced” tab. +If forwarders are not being used, click the “Advanced” tab. Select the "Disable recursion (also disables forwarders)" check box.Note: If the Windows DNS server is in the classified network, this check is Not Applicable. @@ -696,7 +698,7 @@ If forwarders are enabled and configured, this check is not applicable. If forwarders are not enabled, click on the “Advanced” tab and ensure the "Disable recursion (also disables forwarders)" check box is selected. If forwarders are not enabled and configured, and the "Disable recursion (also disables forwarders)" check box in the “Advanced” tab is not selected, this is a finding. -SRG-APP-000383-DNS-000047<GroupDescription></GroupDescription>WDNS-CM-000004Forwarders on an authoritative Windows 2012 DNS Server, if enabled for external resolution, must only forward to either an internal, non-AD-integrated DNS server or to the DoD Enterprise Recursive Services (ERS).<VulnDiscussion>A potential vulnerability of DNS is that an attacker can poison a name server's cache by sending queries that will cause the server to obtain host-to-IP address mappings from bogus name servers that respond with incorrect information. Once a name server has been poisoned, legitimate clients may be directed to non-existent hosts (which constitutes a denial of service), or, worse, hosts that masquerade as legitimate ones to obtain sensitive data or passwords. +SRG-APP-000383-DNS-000047<GroupDescription></GroupDescription>WDNS-CM-000004Forwarders on an authoritative Windows 2012 DNS Server, if enabled for external resolution, must only forward to either an internal, non-AD-integrated DNS server or to the DoD Enterprise Recursive Services (ERS).<VulnDiscussion>A potential vulnerability of DNS is that an attacker can poison a name server's cache by sending queries that will cause the server to obtain host-to-IP address mappings from bogus name servers that respond with incorrect information. Once a name server has been poisoned, legitimate clients may be directed to non-existent hosts (which constitutes a denial of service), or, worse, hosts that masquerade as legitimate ones to obtain sensitive data or passwords. To guard against poisoning, name servers authoritative for .mil domains should be separated functionally from name servers that resolve queries on behalf of internal clients. Organizations may achieve this separation by dedicating machines to each function or, if possible, by running two instances of the name server software on the same machine: one for the authoritative function and the other for the resolving function. In this design, each name server process may be bound to a different IP address or network interface to implement the required segregation.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Log on to the DNS server using the Domain Admin or Enterprise Admin account. @@ -756,7 +758,7 @@ Press Windows Key + R, execute dnsmgmt.msc. On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones. -From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. Note: This requirement applies to any Windows DNS Server which host non-AD-integrated zones even if the DNS servers host AD-integrated zones, too. If the Windows DNS Server only hosts AD-integrated zones and does not host any file-based zones, this is not applicable. Validate this check from the Windows 2012 DNS server being configured/reviewed. @@ -810,9 +812,9 @@ From the expanded list, click to select the zone. Right-click the zone and select DNSSEC, Properties. -Select the KSK Tab. For the "DNSKEY RRSET signature validity period (hours):" setting, configure to a value between 48-168 hours. +Select the KSK Tab. For the "DNSKEY RRSET signature validity period (hours):" setting, configure to a value between 48-168 hours. -Select the ZSK Tab. For the "DNSKEY signature validity period (hours):" setting, configure to a value between 48-168 hours. +Select the ZSK Tab. For the "DNSKEY signature validity period (hours):" setting, configure to a value between 48-168 hours. Note: This check is Not applicable for Windows 2012 DNS Servers that only host Active Directory integrated zones or for Windows 2012 DNS servers on a Classified network. Log on to the DNS server using the account designated as Administrator or DNS Administrator. @@ -827,9 +829,9 @@ Right-click the zone and select DNSSEC, Properties. Select the KSK Tab. -Verify the "DNSKEY signature validity period (hours):” is set to at least 48 hours and no more than 168 hours. +Verify the "DNSKEY signature validity period (hours):” is set to at least 48 hours and no more than 168 hours. -Select the ZSK Tab. +Select the ZSK Tab. Verify the "DNSKEY signature validity period (hours):" is set to at least 48 hours and no more than 168 hours. If either the KSK or ZSK Tab "DNSKEY signature validity period (hours):" values are set to less than 48 hours or more than 168 hours, this is a finding. @@ -855,7 +857,7 @@ Log on to the DNS server using the Domain Admin or Enterprise Admin account. Open an elevated Windows PowerShell prompt on a DNS server using the Domain Admin or Enterprise Admin account. -Type the following command: +Type the following command: PS C:\> Get-DnsServerResourceRecord -ZoneName example.com <enter> @@ -874,7 +876,7 @@ Press Windows Key + R, execute dnsmgmt.msc. On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones. -From the expanded list, click to select the zone. +From the expanded list, click to select the zone. Review the NS records for the zone. @@ -895,10 +897,10 @@ At a command prompt on any system, type: nslookup <enter>; -At the nslookup prompt, type: +At the nslookup prompt, type: server ###.###.###.### <enter>; -(where the ###.###.###.### is replaced by the IP of each NS record) +(where the ###.###.###.### is replaced by the IP of each NS record) Enter a FQDN for a known host record in the zone. @@ -938,7 +940,7 @@ From the expanded list, click to select the zone. Review the SOA information for the zone and obtain the Serial Number. Access each secondary name server for the same zone and review the SOA information. - + Verify the Serial Number is the same on all authoritative name servers. If the Serial Number is not the same on one or more authoritative name servers, this is a finding.SRG-APP-000516-DNS-000089<GroupDescription></GroupDescription>WDNS-CM-000014The Windows 2012 DNS Server must be configured to enable DNSSEC Resource Records.<VulnDiscussion>The specification for a digital signature mechanism in the context of the DNS infrastructure is in IETF's DNSSEC standard. In DNSSEC, trust in the public key (for signature verification) of the source is established not by going to a third party or a chain of third parties (as in public key infrastructure [PKI] chaining), but by starting from a trusted zone (such as the root zone) and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. The public key of the trusted zone is called the trust anchor. After authenticating the source, the next process DNSSEC calls for is to authenticate the response. DNSSEC mechanisms involve two main processes: sign and serve, and verify signature. @@ -960,8 +962,8 @@ Press Windows Key + R, execute dnsmgmt.msc. On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones. From the expanded list, click to select each zone. - -Review the RRs for each zone and verify all of the DNSEC record types are included for the zone. + +Review the RRs for each zone and verify all of the DNSEC record types are included for the zone. NOTE: The DS (Delegation Signer)record should also exist but the requirement for it is validated under WDNS-SC-000011. @@ -973,7 +975,7 @@ If the zone does not show all of the DNSSEC record types, this is a finding.SRG-APP-000516-DNS-000091<GroupDescription></GroupDescription>WDNS-CM-000016For zones split between the external and internal sides of a network, the RRs for the external hosts must be separate from the RRs for the internal hosts.<VulnDiscussion>Authoritative name servers for an enterprise may be configured to receive requests from both external and internal clients. +If the specified encryption algorithm is not RsaSha1 or stronger, this is a finding.SRG-APP-000516-DNS-000091<GroupDescription></GroupDescription>WDNS-CM-000016For zones split between the external and internal sides of a network, the RRs for the external hosts must be separate from the RRs for the internal hosts.<VulnDiscussion>Authoritative name servers for an enterprise may be configured to receive requests from both external and internal clients. -External clients need to receive RRs that pertain only to public services (public Web server, mail server, etc.) +External clients need to receive RRs that pertain only to public services (public Web server, mail server, etc.) -Internal clients need to receive RRs pertaining to public services as well as internal hosts. +Internal clients need to receive RRs pertaining to public services as well as internal hosts. The zone information that serves the RRs on both the inside and the outside of a firewall should be split into different physical files for these two types of clients (one file for external clients and one file for internal clients).</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Remove any RRs from the internal zones for which the resolution is for an external IP address. @@ -1021,9 +1023,9 @@ For each zone, review the records. If any RRs (Resource Records) on an internal DNS server resolve to IP addresses located outside the internal DNS server's network, this is a finding. -If any RRs (Resource Records) on an external DNS server resolve to IP addresses located inside the network, this is a finding.SRG-APP-000516-DNS-000092<GroupDescription></GroupDescription>WDNS-CM-000017In a split DNS configuration, where separate name servers are used between the external and internal networks, the external name server must be configured to not be reachable from inside resolvers.<VulnDiscussion>Instead of having the same set of authoritative name servers serve different types of clients, an enterprise could have two different sets of authoritative name servers. +If any RRs (Resource Records) on an external DNS server resolve to IP addresses located inside the network, this is a finding.SRG-APP-000516-DNS-000092<GroupDescription></GroupDescription>WDNS-CM-000017In a split DNS configuration, where separate name servers are used between the external and internal networks, the external name server must be configured to not be reachable from inside resolvers.<VulnDiscussion>Instead of having the same set of authoritative name servers serve different types of clients, an enterprise could have two different sets of authoritative name servers. -One set, called external name servers, can be located within a DMZ; these would be the only name servers that are accessible to external clients and would serve RRs pertaining to hosts with public services (Web servers that serve external Web pages or provide B2C services, mail servers, etc.) +One set, called external name servers, can be located within a DMZ; these would be the only name servers that are accessible to external clients and would serve RRs pertaining to hosts with public services (Web servers that serve external Web pages or provide B2C services, mail servers, etc.) The other set, called internal name servers, is to be located within the firewall and should be configured so they are not reachable from outside and hence provide naming services exclusively to internal clients.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Configure the external DNS server's firewall policy, or the network firewall, to block queries from internal hosts.Consult with the System Administrator to review the external Windows DNS Server's HBSS firewall policy. @@ -1134,8 +1136,8 @@ If internal and external DNS servers have not been implemented for zones which r Press Windows Key + R, execute dnsmgmt.msc. Right-click the DNS server, select "Properties". Select the "Root Hints" tab. -Remove the root hints from the DNS Manager, the CACHE.DNS file and from Active Directory for name servers outside of the internal network. -Replace the existing root hints with new root hints of internal servers. +Remove the root hints from the DNS Manager, the CACHE.DNS file and from Active Directory for name servers outside of the internal network. +Replace the existing root hints with new root hints of internal servers. If the DNS server is forwarding, click to select the : "Do not use recursion for this domain" check box on the "Forwarders" tab in DNS Manager to make sure that the root hints will not be used. Note: If the Windows DNS server is in the classified network, this check is Not Applicable. Log on to the authoritative DNS server using the Domain Admin or Enterprise Admin account. @@ -1156,14 +1158,14 @@ Press Windows Key + R, execute dnsmgmt.msc. On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones. From the expanded list, click to select the zone. - + Confirm with the DNS administrator that the hosts defined in the zone files do not resolve to hosts in another zone with its fully qualified domain name. The exceptions are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms. In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated. Additional exceptions are CNAME records in a multi-domain Active Directory environment pointing to hosts in other internal domains in the same multi-domain environment. -If resource records are maintained that resolve to a fully qualified domain name in another zone, and the usage is not for resource records resolving to hosts that are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms with a documented and approved mission need, this is a finding.SRG-APP-000516-DNS-000114<GroupDescription></GroupDescription>WDNS-CM-000025The Windows 2012 DNS Servers zone files must not include CNAME records pointing to a zone with lesser security for more than six months.<VulnDiscussion>The use of CNAME records for exercises, tests, or zone-spanning aliases should be temporary (e.g., to facilitate a migration). When a host name is an alias for a record in another zone, an adversary has two points of attack: the zone in which the alias is defined and the zone authoritative for the alias's canonical name. This configuration also reduces the speed of client resolution because it requires a second lookup after obtaining the canonical name. Furthermore, in the case of an authoritative name server, this information is promulgated throughout the enterprise to caching servers and thus compounds the vulnerability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Remove any zone-spanning CNAME records that have been active for more than six months, which are not supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms. +If resource records are maintained that resolve to a fully qualified domain name in another zone, and the usage is not for resource records resolving to hosts that are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms with a documented and approved mission need, this is a finding.SRG-APP-000516-DNS-000114<GroupDescription></GroupDescription>WDNS-CM-000025The Windows 2012 DNS Servers zone files must not include CNAME records pointing to a zone with lesser security for more than six months.<VulnDiscussion>The use of CNAME records for exercises, tests, or zone-spanning (pointing to zones with lesser security) aliases should be temporary (e.g., to facilitate a migration) and not be in place for more than six months. When a host name is an alias for a record in another zone, an adversary has two points of attack: the zone in which the alias is defined and the zone authoritative for the alias's canonical name. This configuration also reduces the speed of client resolution because it requires a second lookup after obtaining the canonical name. Furthermore, in the case of an authoritative name server, this information is promulgated throughout the enterprise to caching servers and thus compounds the vulnerability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Remove any zone-spanning CNAME records that have been active for more than six months, which are not supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms. -In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated (AO approval of use of a commercial cloud offering would satisfy this requirement).Log on to the DNS server using the Domain Admin or Enterprise Admin account. +In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated (AO approval of use of a commercial cloud offering would satisfy this requirement).Log on to the DNS server using the Domain Admin or Enterprise Admin account. Press Windows Key + R, execute dnsmgmt.msc. @@ -1175,7 +1177,8 @@ Review the RRs to confirm that there are no CNAME records older than 6 months. The exceptions are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms. In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated (AO approval of use of a commercial cloud offering would satisfy this requirement). Additional exceptions are CNAME records in a multi-domain Active Directory environment pointing to hosts in other internal domains in the same multi-domain environment. -If there are zone-spanning CNAME records older than 6 months and the CNAME records resolve to anything other than fully qualified domain names for glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms with an AO-approved and documented mission need, this is a finding.SRG-APP-000516-DNS-000500<GroupDescription></GroupDescription>WDNS-CM-000026Non-routable IPv6 link-local scope addresses must not be configured in any zone.<VulnDiscussion>IPv6 link-local scope addresses are not globally routable and must not be configured in any DNS zone. Similar to RFC1918 addresses, if a link-local scope address is inserted into a zone provided to clients, most routers will not forward this traffic beyond the local subnet.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366The SA should remove any link-local addresses and replace with appropriate Site-Local or Global scope addresses.Log on to the DNS server using the Domain Admin or Enterprise Admin account. +If there are zone-spanning (i.e., zones of lesser security)CNAME records older than 6 months and the CNAME records resolve to anything other than fully qualified domain names for glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms with an AO-approved and documented mission need, this is a finding. +SRG-APP-000516-DNS-000500<GroupDescription></GroupDescription>WDNS-CM-000026Non-routable IPv6 link-local scope addresses must not be configured in any zone.<VulnDiscussion>IPv6 link-local scope addresses are not globally routable and must not be configured in any DNS zone. Similar to RFC1918 addresses, if a link-local scope address is inserted into a zone provided to clients, most routers will not forward this traffic beyond the local subnet.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366The SA should remove any link-local addresses and replace with appropriate Site-Local or Global scope addresses.Log on to the DNS server using the Domain Admin or Enterprise Admin account. Press Windows Key + R, execute dnsmgmt.msc. @@ -1201,7 +1204,7 @@ Verify if any contain both IPv4 and IPv6 addresses. If any hostnames contain both IPv4 and IPv6 addresses, confirm with the SA that the actual hosts are IPv6-aware. -If any zone contains hosts with both IPv4 and IPv6 addresses but are determined to be non-IPv6-aware, this is a finding.SRG-APP-000516-DNS-000500<GroupDescription></GroupDescription>WDNS-CM-000028When IPv6 protocol is installed, the server must also be configured to answer for IPv6 AAAA records.<VulnDiscussion>To prevent the possibility of a denial of service in relation to an IPv4 DNS server trying to respond to IPv6 requests, the server should be configured not to listen on any of its IPv6 interfaces unless it does contain IPv6 AAAA resource records in one of the zones.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Log onto the DNS server. +If any zone contains hosts with both IPv4 and IPv6 addresses but are determined to be non-IPv6-aware, this is a finding.SRG-APP-000516-DNS-000500<GroupDescription></GroupDescription>WDNS-CM-000028IPv6 protocol must be disabled unless the Windows 2012 DNS server is configured to answer for and hosting IPv6 AAAA records.<VulnDiscussion>To prevent the possibility of a denial of service in relation to an IPv4 DNS server trying to respond to IPv6 requests, the server should be configured not to listen on any of its IPv6 interfaces unless it does contain IPv6 AAAA resource records in one of the zones.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366Log onto the DNS server. Access Group Policy Management. @@ -1211,11 +1214,13 @@ As an alternative to using the GPO setting, the registry setting may also be alt HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters \ Set the value for “DisabledComponents” to “255 (0xff)”. -Log on to the DNS server using the Domain Admin or Enterprise Admin account. +Note: If the Windows 2012 DNS server is hosting IPv6 records, this requirement is not applicable. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account. -From a command prompt, run regedit. -In the User Account Control dialog box, click Continue. -In Registry Editor, locate and then click the following registry subkey: +From a command prompt, run regedit. +In the User Account Control dialog box, click Continue. +In Registry Editor, locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters \ Verify the value for “DisabledComponents” is “255 (0xff)”. @@ -1338,7 +1343,7 @@ Click “Connection Security Rules”. Confirm at least one rule is configured for TCP 53. -Double-click on each Rule to verify the following: +Double-click on each Rule to verify the following: On the “Authentication” tab, "Authentication mode:" is set to "Request authentication for inbound and outbound connections". @@ -1364,7 +1369,7 @@ From the context menu that appears, click DNS Manager. In the DNS Manager console tree on the DNS server being validated, navigate to Forward Lookup Zones. -Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. Authenticity of zone transfers within Windows AD integrated zones is accomplished by AD replication. For zones which are completely AD-integrated, this check is not a finding. @@ -1458,7 +1463,7 @@ Log on to the DNS server using the account designated as Administrator or DNS Ad In the DNS Manager console tree on the DNS server being validated, navigate to Forward Lookup Zones. -Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using saved parameters or custom parameters. +Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using saved parameters or custom parameters. Note: This check is Not applicable for Windows 2012 DNS Servers that only host Active Directory integrated zones or for Windows 2012 DNS servers on a Classified network. @@ -1525,10 +1530,10 @@ Navigate to the following location: Right-click on each sub-folder, choose “Properties”, click on the “Security” tab, and click on the “Advanced” button. -Click on "Change" next to the listed Owner and change to be the account under which the DNS Server Service is running. +Click on "Change" next to the listed Owner and change to be the account under which the DNS Server Service is running. Access Services on the Windows DNS Server and locate the DNS Server Service. -Determine the account under which the DNS Server Service is running. +Determine the account under which the DNS Server Service is running. Access Windows Explorer. @@ -1547,7 +1552,7 @@ If any other user or group is listed as OWNER of the %ALLUSERSPROFILE%\Microsoft Navigate to the following location: %ALLUSERSPROFILE%\Microsoft\Crypto -Modify permissions on the folder, sub-folders and files to “FULL CONTROL” for “SYSTEM” and Administrators and to “READ” for all other Users/Groups. +Modify permissions on the folder, sub-folders and files to “FULL CONTROL” for “SYSTEM” and Administrators and to “READ” for all other Users/Groups. Access Windows Explorer. Navigate to the following location: @@ -1592,7 +1597,7 @@ Press Windows Key + R, execute dnsmgmt.msc. On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS Server, and then expand Forward Lookup Zones. -From the expanded list, click to select the zone. +From the expanded list, click to select the zone. Review the zone's RRs in the right window pane. @@ -1616,7 +1621,7 @@ From the context menu that appears, click DNS Manager. In the DNS Manager console tree on the DNS server being validated, navigate to Forward Lookup Zones. -Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. Note: This check is Not applicable for Windows 2012 DNS Servers that only host Active Directory integrated zones or for Windows 2012 DNS servers on a Classified network. Authenticity of query responses is provided with DNSSEC signing of zones. @@ -1657,7 +1662,7 @@ Section: Answer IP4Address: ###.###.###.### If the results do not show the RRSIG and signature information, this is a finding. -SRG-APP-000420-DNS-000053<GroupDescription></GroupDescription>WDNS-SC-000003The Windows 2012 DNS Servers IP address must be statically defined and configured locally on the server.<VulnDiscussion>The major threat associated with DNS forged responses or failures are the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. By requiring remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service, data origin is validated. +SRG-APP-000420-DNS-000053<GroupDescription></GroupDescription>WDNS-SC-000003The Windows 2012 DNS Servers IP address must be statically defined and configured locally on the server.<VulnDiscussion>The major threat associated with DNS forged responses or failures are the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. By requiring remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service, data origin is validated. Ensuring all name servers have static IP addresses makes it possible to configure restricted DNS communication, such as with DNSSEC, between the name servers.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366CCI-002463Log on to the DNS server using the Domain Admin or Enterprise Admin account. @@ -1689,7 +1694,7 @@ Press Windows Key + R, execute dnsmgmt.msc. On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones. -From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. Note: This check is Not applicable for Windows 2012 DNS Servers that only host Active Directory integrated zones or for Windows 2012 DNS servers on a Classified network. By default, when DNS servers are configured with DNSSEC signed zones, they will automatically respond to query requests, providing validating data in the response, whenever the query requests that validation. Since this takes place inherently when the zone is signed with DNSSEC, the requirement is satisfied by ensuring zones are signed. @@ -1742,7 +1747,7 @@ Press Windows Key + R, execute dnsmgmt.msc. On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones. -From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. Note: This check is Not applicable for Windows 2012 DNS Servers that only host Active Directory integrated zones or for Windows 2012 DNS servers on a Classified network. Validate this check from the Windows 2012 DNS server being configured/reviewed. @@ -1783,7 +1788,7 @@ IP4Address: ###.###.###.### If the results do not show the RRSIG and signature information, this is a finding. SRG-APP-000422-DNS-000055<GroupDescription></GroupDescription>WDNS-SC-000006WINS lookups must be disabled on the Windows 2012 DNS Server.<VulnDiscussion>The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. By requiring remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service, data origin is validated. -A DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS, to map between host/service names and network addresses, must provide other means to assure the authenticity and integrity of response data. +A DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS, to map between host/service names and network addresses, must provide other means to assure the authenticity and integrity of response data. In the case of DNS, employ DNSSEC to provide an additional data origin and integrity artifacts along with the authoritative data the system returns in response to DNS name/address resolution queries. @@ -1813,7 +1818,7 @@ Verify the "Use WINS forward lookup" check box is not selected. If the "Use WINS forward lookup" check box is selected, this is a finding.SRG-APP-000422-DNS-000055<GroupDescription></GroupDescription>WDNS-SC-000007The Windows 2012 DNS Server must use DNSSEC data within queries to confirm data integrity to DNS resolvers.<VulnDiscussion>The major threat associated with DNS forged responses or failures is the integrity of the DNS data returned in the response. The principle of DNSSEC is to mitigate this threat by providing data origin authentication, establishing trust in the source. By requiring remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service, data origin is validated. -A DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS, to map between host/service names and network addresses, must provide other means to assure the authenticity and integrity of response data. +A DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS, to map between host/service names and network addresses, must provide other means to assure the authenticity and integrity of response data. In the case of DNS, employ DNSSEC to provide an additional data origin and integrity artifacts along with the authoritative data the system returns in response to DNS name/address resolution queries.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002462Sign, or re-sign, the hosted zone(s) on the DNS server being validated. @@ -1864,7 +1869,7 @@ IP4Address: ###.###.###.### If the results do not show the RRSIG and signature information, this is a finding. SRG-APP-000214-DNS-000025<GroupDescription></GroupDescription>WDNS-SC-000008The Windows 2012 DNS Server must be configured with the DS RR carrying the signature for the RR that contains the public key of the child zone.<VulnDiscussion>If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its sub domain, from the top of the DNS hierarchy down. -A DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS, to map between host/service names and network addresses, must provide other means to assure the authenticity and integrity of response data. +A DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS, to map between host/service names and network addresses, must provide other means to assure the authenticity and integrity of response data. In DNS, trust in the public key of the source is established by starting from a trusted name server and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. @@ -1881,7 +1886,7 @@ Press Windows Key + R, execute dnsmgmt.msc. On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones. -From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. Note: This check is Not applicable for Windows 2012 DNS Servers that only host Active Directory integrated zones or for Windows 2012 DNS servers on a Classified network. Validate this check from the Windows 2012 DNS server being configured/reviewed. @@ -1935,7 +1940,7 @@ Press Windows Key + R, execute dnsmgmt.msc. On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones. From the expanded list, click to select the zone. - + Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters.Note: This check is Not applicable for Windows 2012 DNS Servers that only host Active Directory integrated zones or for Windows 2012 DNS servers on a Classified network. Log on to the DNS server using the Domain Admin or Enterprise Admin account. @@ -1944,7 +1949,7 @@ Press Windows Key + R, execute dnsmgmt.msc. On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones. -From the expanded list, click to select the zone. +From the expanded list, click to select the zone. Review the records for the zone and ensure the complete RRSet of records are present: RRSIG, NSEC3, DNSKEY, indicating DNSSEC compliance. @@ -1955,7 +1960,7 @@ In the Group Policy Management console tree, under Domains >; domainname > In the Group Policy Management Editor console tree, navigate to Computer Configuration >; Policies >; Windows Settings >; Name Resolution Policy. In the details pane, under Create Rules and to which part of the namespace does this rule apply, choose Suffix from the drop-down list and type domain.mil next to Suffix. - + On the DNSSEC tab, select the Enable DNSSEC in this rule check box and then under Validation select the Require DNS clients to check that name and address data has been validated by the DNS server check box. In the bottom right corner, click Create and then verify that a rule for domain.mil was added under Name Resolution Policy Table. @@ -1977,7 +1982,7 @@ get-dnsclientnrptpolicy <enter> In the results, verify the "DnsSecValidationRequired" is True. -If there are no results to the get-dnsclientnrptpolicy cmdlet or the "DnsSecValidationRequired" is not True, this is a finding.SRG-APP-000215-DNS-000026<GroupDescription></GroupDescription>WDNS-SC-000011The Windows 2012 DNS Server must be configured to validate an authentication chain of parent and child domains via response data.<VulnDiscussion>If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its sub domain, from the top of the DNS hierarchy down. +If there are no results to the get-dnsclientnrptpolicy cmdlet or the "DnsSecValidationRequired" is not True, this is a finding.SRG-APP-000215-DNS-000026<GroupDescription></GroupDescription>WDNS-SC-000011The Windows 2012 DNS Server must be configured to validate an authentication chain of parent and child domains via response data.<VulnDiscussion>If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its sub domain, from the top of the DNS hierarchy down. Like the DNSKEY resource record, the delegation signer (DS) resource record can be used to create a trust anchor for a signed zone. The DS record is smaller in size than a DNSKEY record because it contains only a hash of the public key. The DS record is not added to a zone during the signing process like some DNSSEC-related resource records, even if a delegation already exists in the zone. To add a DS record, you must manually add or import it. Fortunately, the DS resource record set (DSSET) is automatically added as a file to the Key Master when a zone is signed. The DSSET file can be used with the Import-DnsServerResourceRecordDS cmdlet to import DS records to the parent zone. @@ -1990,12 +1995,12 @@ Starting from a trusted name server (such as the root name server) and down to t This control enables the DNS to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. Without indication of the security status of a child domain and enabling verification of a chain of trust, integrity and availability of the DNS infrastructure cannot be assured. </VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001663A DS records must be added manually or imported. -The DS resource record set (DSSET) is automatically added as a file to the Key Master when a zone is signed. +The DS resource record set (DSSET) is automatically added as a file to the Key Master when a zone is signed. This file can be used with the Import-DnsServerResourceRecordDS cmdlet to import DS records to the parent zone. Example: -PS C:\> Import-DnsServerResourceRecordDS -ZoneName adatum.com -DSSetFile "c:\windows\system32\dns\dsset-corp.adatum.com" +PS C:\> Import-DnsServerResourceRecordDS -ZoneName adatum.com -DSSetFile "c:\windows\system32\dns\dsset-corp.adatum.com" Note: This check is Not applicable for Windows 2012 DNS Servers that only host Active Directory integrated zones or for Windows 2012 DNS servers on a Classified network. @@ -2048,7 +2053,7 @@ Right-click Trust Points, point to Import, and then click DNSKEY. In the Import DNSKEY dialog box, type \\primaryhost\dns\keyset-domain.mil (where primaryhost represent the FQDN of the Primary DNS Server and domain.mil represents the zone(s)). -Click OK. +Click OK. Note: This check is Not applicable for Windows 2012 DNS Servers that only host Active Directory integrated zones or for Windows 2012 DNS servers on a Classified network. Log onto each of the validating Windows 2012 DNS Servers. @@ -2156,7 +2161,7 @@ Press Windows Key + R, execute dnsmgmt.msc. On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones. -From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. Note: This check is Not applicable for Windows 2012 DNS Servers that only host Active Directory integrated zones or for Windows 2012 DNS servers on a Classified network. Validate this check from the Windows 2012 DNS server being configured/reviewed. @@ -2205,7 +2210,7 @@ Press Windows Key + R, execute dnsmgmt.msc. On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones. -From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. Note: This check is Not applicable for Windows 2012 DNS Servers that only host Active Directory integrated zones or for Windows 2012 DNS servers on a Classified network. Validate this check from the Windows 2012 DNS server being configured/reviewed. @@ -2254,7 +2259,7 @@ Press Windows Key + R, execute dnsmgmt.msc. On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones. -From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. Note: This check is Not applicable for Windows 2012 DNS Servers that only host Active Directory integrated zones or for Windows 2012 DNS servers on a Classified network. Validate this check from the Windows 2012 DNS server being configured/reviewed. @@ -2298,9 +2303,9 @@ If the results do not show the RRSIG and signature information, this is a findin TSIG and SIG(0) are not configurable in Windows 2012 DNS Server. To meet the requirement for authentication between Windows DNS servers, IPsec will be implemented between the Windows DNS servers which hosts any non-AD-integrated zones.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001184Complete the following procedures twice for each pair of name servers. - + First create a rule for UDP connections, and then create a rule for TCP connections. - + Refer to the U_Windows_Domain_Name_Service_2012_Overview.pdf for Microsoft links for this procedure. Log on to the DNS server using the Domain Admin or Enterprise Admin account. @@ -2330,7 +2335,7 @@ From the "CA name:", click Browse and select the certificate generated by the in On Profile, accept default selections, click Next. On Name, enter a name applicable to the rule's function (i.e., DNSSEC UDP), click Finish.NOTE: This requirement applies to any Windows 2012 DNS Servers which host non-AD-integrated zones (file based) even if the DNS servers host AD-integrated zones, too. - + If the Windows 2012 DNS Servers only host AD-integrated zones, this requirement is not applicable. To protect authenticity of zone transfers between Windows 2012 DNS Servers with file based zones, IPsec must be configured on each pair of name servers in a zone transfer transaction for those zones. @@ -2354,7 +2359,7 @@ If Rules exist, double-click on each Rule to verify the following: For the "Authentication:" tab, click on the "Customize..." button. On the Authentication tab, verify "Authentication mode:" is set to "Request authentication for inbound and outbound connections". - + Confirm the "Signing Algorithm" is set to "RSA (default)". Under "Method", ensure the "Advanced:" radio button is selected. @@ -2385,7 +2390,7 @@ From the context menu that appears, click DNS Manager. In the DNS Manager console tree on the DNS server being validated, navigate to Forward Lookup Zones. -Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. Note: This check is Not applicable for Windows 2012 DNS Servers that only host Active Directory integrated zones or for Windows 2012 DNS servers on a Classified network. Once resource records are received by a DNS server via a secure dynamic update, the resource records will automatically become signed by DNSSEC as long as the zone was originally signed by DNSSEC. Authenticity of query responses for resource records dynamically updated can be validated by querying for whether the zone/record is signed by DNSSEC. @@ -2430,7 +2435,7 @@ If the results do not show the RRSIG and signature information, this is a findin In the DNS Manager console tree on the DNS server being validated, navigate to Forward Lookup Zones. -Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using saved parameters or custom parameters. +Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using saved parameters or custom parameters. Note: This check is Not applicable for Windows 2012 DNS Servers that only host Active Directory integrated zones or for Windows 2012 DNS servers on a Classified network. Authenticity of query responses is provided with DNSSEC signing of zones. @@ -2476,7 +2481,7 @@ Fix Text: Sign, or re-sign, the hosted zone(s) on the DNS server being validated In the DNS Manager console tree on the DNS server being validated, navigate to Forward Lookup Zones. -Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using saved parameters or custom parameters. +Right-click the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using saved parameters or custom parameters. SRG-APP-000427-DNS-000060<GroupDescription></GroupDescription>WDNS-SC-000022The Windows 2012 DNS Server must only allow the use of an approved DoD PKI-established certificate authorities for verification of the establishment of protected transactions.<VulnDiscussion>Untrusted Certificate Authorities (CA) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DoD systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DoD-approved CA, trust of this CA has not been established. The DoD will only accept PKI certificates obtained from a DoD-approved internal or external certificate authority. Reliance on CAs for the establishment of secure sessions includes, for example, the use of SSL/TLS certificates. @@ -2486,9 +2491,9 @@ TSIG and SIG(0) are not configurable in Windows 2012 DNS Server. To meet the req NOTE: If multiple certificates from the same CA are present on the DNS server, IPsec authentication might fail due to an incorrect certificate being chosen. For this purpose, an Active Directory Certificate Services (AD CS) role must be installed and configured as an Enterprise certification authority (CA). Refer to the U_Windows_Domain_Name_Service_2012_Overview.pdf for references on deploying certificates for this procedure.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002470Complete the following procedures twice for each pair of name servers. - + First create a rule for UDP connections, and then create a rule for TCP connections. - + Refer to the U_Windows_Domain_Name_Service_2012_Overview.pdf for Microsoft links for this procedure. Log on to the DNS server using the Domain Admin or Enterprise Admin account. @@ -2539,7 +2544,7 @@ Double-click on each Rule to verify the following: For the "Authentication:" tab, click on the "Customize..." button. On the Authentication tab, verify "Authentication mode:" is set to "Request authentication for inbound and outbound connections". - + Confirm the "Signing Algorithm" is set to "RSA (default)". Under "Method", ensure the "Advanced:" radio button is selected. Click on the "Customize" button. @@ -2554,7 +2559,7 @@ If the certificate used does not meet the requirements, this is a finding.DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001199To ensure the cryptographic keys are protected after being backed up to tape or other medium, develop a backup policy to include the protection of backup date to be at or above the same level as the DNS server itself. To ensure the cryptographic keys are protected after being backed up to another medium (tape, disk, SAN, etc.), consult with the System Administrator to determine the backup policy in place for the DNS Server. -Determine how and where backed up data is being stored. +Determine how and where backed up data is being stored. Verify the protection of the backup medium is secured to the same level, or higher, as the server itself. @@ -2608,19 +2613,19 @@ Run "gpedit.msc". Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment. -If any accounts or groups other than the following are granted the "Allow log on through Remote Desktop Services" user right, this is a finding: +If any accounts or groups other than the following are granted the "Allow log on through Remote Desktop Services" user right, this is a finding: Administrators Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment. -If the following accounts or groups are not defined for the "Deny access to this computer from the network" user right, this is a finding: +If the following accounts or groups are not defined for the "Deny access to this computer from the network" user right, this is a finding: Guests Group Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> User Rights Assignment. -If the following accounts or groups are not defined for the "Deny log on locally" user right, this is a finding: +If the following accounts or groups are not defined for the "Deny log on locally" user right, this is a finding: Guests GroupSRG-APP-000247-DNS-000036<GroupDescription></GroupDescription>WDNS-SC-000027The Windows 2012 DNS Server must use DNS Notify to prevent denial of service through increase in workload.<VulnDiscussion>In the case of application DoS attacks, care must be taken when designing the application to ensure the application makes the best use of system resources. SQL queries have the potential to consume large amounts of CPU cycles if they are not tuned for optimal performance. Web services containing complex calculations requiring large amounts of time to complete can bog down if too many requests for the service are encountered within a short period of time.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-001095Log on to the DNS server using the Domain Admin or Enterprise Admin account. @@ -2677,7 +2682,7 @@ Press Windows Key + R, execute dnsmgmt.msc. On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones. -From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. Note: This check is Not applicable for Windows 2012 DNS Servers that only host Active Directory integrated zones or for Windows 2012 DNS servers on a Classified network. Validate this check from the Windows 2012 DNS server being configured/reviewed. @@ -2724,7 +2729,7 @@ Press Windows Key + R, execute dnsmgmt.msc. On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones. -From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. Note: This check is Not applicable for Windows 2012 DNS Servers that only host Active Directory integrated zones or for Windows 2012 DNS servers on a Classified network. Validate this check from the Windows 2012 DNS server being configured/reviewed. @@ -2771,7 +2776,7 @@ Press Windows Key + R, execute dnsmgmt.msc. On the opened DNS Manager snap-in from the left pane, expand the server name for the DNS server, and then expand Forward Lookup Zones. -From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. +From the expanded list, right-click to select the zone (repeat for each hosted zone), point to DNSSEC, and then click Sign the Zone, either using approved saved parameters or approved custom parameters. Note: This check is Not applicable for Windows 2012 DNS Servers that only host Active Directory integrated zones or for Windows 2012 DNS servers on a Classified network. Validate this check from the Windows 2012 DNS server being configured/reviewed. @@ -2857,7 +2862,7 @@ This can include conducting a graceful application shutdown to avoid losing info If a component such as the DNSSEC or TSIG/SIG(0) signing capabilities were to fail, the DNS server should shut itself down to prevent continued execution without the necessary security components in place. Transactions such as zone transfers would not be able to work correctly anyway in this state.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-000366CCI-001328Implement a third-party monitoring system to detect and notify the system administrator upon component failure or, at a minimum, document and implement a procedure to review the diagnostic logs on a routine basis every day.Notification to system administrator is not configurable in Windows DNS Server. In order for system administrators to be notified when a component fails, the system administrator would need to implement a third-party monitoring system. At a minimum, the system administrator should have a documented procedure in place to review the diagnostic logs on a routine basis every day. If a third-party monitoring system is not in place to detect and notify the system administrator upon component failures and the system administrator does not have a documented procedure in place to review the diagnostic logs on a routine basis every day, this is a finding. -SRG-APP-000473-DNS-000072<GroupDescription></GroupDescription>WDNS-SI-000006The Windows 2012 DNS Server must perform verification of the correct operation of security functions: upon system start-up and/or restart; upon command by a user with privileged access; and/or every 30 days.<VulnDiscussion>Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Without verification, security functions may not operate correctly and this failure may go unnoticed. +SRG-APP-000473-DNS-000072<GroupDescription></GroupDescription>WDNS-SI-000006The Windows 2012 DNS Server must perform verification of the correct operation of security functions: upon system start-up and/or restart; upon command by a user with privileged access; and/or every 30 days.<VulnDiscussion>Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Without verification, security functions may not operate correctly and this failure may go unnoticed. Notifications provided by information systems include, for example, electronic alerts to system administrators, messages to local computer consoles, and/or hardware indications, such as lights. @@ -2866,11 +2871,13 @@ The DNS server should perform self-tests, such as at server start-up, to confirm Check to ensure McAfee HBSS is installed and fully operational on the Windows DNS Server. If all required HBSS products are not installed and/or the installed products are not enabled, this is a finding. -SRG-APP-000474-DNS-000073<GroupDescription></GroupDescription>WDNS-SI-000007The Windows 2012 DNS Server must log the event and notify the system administrator when anomalies in the operation of the signed zone transfers are discovered.<VulnDiscussion>Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Notifications provided by information systems include messages to local computer consoles, and/or hardware indications, such as lights. +SRG-APP-000474-DNS-000073<GroupDescription></GroupDescription>WDNS-SI-000007The Windows 2012 DNS Server must log the event and notify the system administrator when anomalies in the operation of the signed zone transfers are discovered.<VulnDiscussion>Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Notifications provided by information systems include messages to local computer consoles, and/or hardware indications, such as lights. If anomalies are not acted upon, security functions may fail to secure the system. -The DNS server does not have the capability of shutting down or restarting the information system. The DNS server can be configured to generate audit records when anomalies are discovered, and the OS/NDM can then trigger notification messages to the system administrator based on the presence of those audit records.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002699Implement a third-party monitoring system to detect and notify the ISSO/ISSM/DNS administrator if functionality of DNSSEC/TSIG has been removed or broken or, at a minimum, document and implement a procedure to review the diagnostic logs on a routine basis every day.Notification to system administrator is not configurable in Windows 2012. In order for administrator to be notified if functionality of DNSSEC/TSIG has been removed or broken, the ISSO/ISSM/DNS administrator would need to implement a third-party monitoring system. At a minimum, the ISSO/ISSM/DNS administrator should have a documented procedure in place to review the diagnostic logs on a routine basis every day. +The DNS server does not have the capability of shutting down or restarting the information system. The DNS server can be configured to generate audit records when anomalies are discovered, and the OS/NDM can then trigger notification messages to the system administrator based on the presence of those audit records.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>DPMS Target Windows 2012 DNSDISADPMS TargetWindows 2012 DNS2771CCI-002699Implement a third-party monitoring system to detect and notify the ISSO/ISSM/DNS administrator if functionality of DNSSEC/TSIG has been removed or broken or, at a minimum, document and implement a procedure to review the diagnostic logs on a routine basis every day.Note: If only zones hosted are AD-integrated zones, this check is not applicable. + +Notification to system administrator is not configurable in Windows 2012. In order for administrator to be notified if functionality of DNSSEC/TSIG has been removed or broken, the ISSO/ISSM/DNS administrator would need to implement a third-party monitoring system. At a minimum, the ISSO/ISSM/DNS administrator should have a documented procedure in place to review the diagnostic logs on a routine basis every day. If a third-party monitoring system is not in place to detect and notify the ISSO/ISSM/DNS administrator if functionality of DNSSEC/TSIG has been removed or broken and the ISSO/ISSM/DNS administrator does not have a documented procedure in place to review the diagnostic logs on a routine basis every day, this is a finding.SRG-APP-000275-DNS-000040<GroupDescription></GroupDescription>WDNS-SI-000008The Windows 2012 DNS Server must be configured to notify the ISSO/ISSM/DNS administrator when functionality of DNSSEC/TSIG has been removed or broken.<VulnDiscussion>Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. If personnel are not notified of failed security verification tests, they will not be able to take corrective action and the unsecure condition(s) will remain. Notifications provided by information systems include messages to local computer consoles, and/or hardware indications, such as lights. diff --git a/source/StigData/Processed/WindowsDnsServer-2012R2-1.13.org.default.xml b/source/StigData/Processed/WindowsDnsServer-2012R2-1.15.org.default.xml similarity index 89% rename from source/StigData/Processed/WindowsDnsServer-2012R2-1.13.org.default.xml rename to source/StigData/Processed/WindowsDnsServer-2012R2-1.15.org.default.xml index 94e5a5127..38da82351 100644 --- a/source/StigData/Processed/WindowsDnsServer-2012R2-1.13.org.default.xml +++ b/source/StigData/Processed/WindowsDnsServer-2012R2-1.15.org.default.xml @@ -5,7 +5,7 @@ Each setting in this file is linked by STIG ID and the valid range is in an associated comment. --> - + diff --git a/source/StigData/Processed/WindowsDnsServer-2012R2-1.13.xml b/source/StigData/Processed/WindowsDnsServer-2012R2-1.15.xml similarity index 98% rename from source/StigData/Processed/WindowsDnsServer-2012R2-1.13.xml rename to source/StigData/Processed/WindowsDnsServer-2012R2-1.15.xml index 7599a508e..f3579e463 100644 --- a/source/StigData/Processed/WindowsDnsServer-2012R2-1.13.xml +++ b/source/StigData/Processed/WindowsDnsServer-2012R2-1.15.xml @@ -1,4 +1,4 @@ - + <VulnDiscussion>All caching name servers must be authoritative for the root zone because, without this starting point, they would have no knowledge of the DNS infrastructure and thus would be unable to respond to any queries. The security risk is that an adversary could change the root hints and direct the caching name server to a bogus root server. At that point, every query response from that name server is suspect, which would give the adversary substantial control over the network communication of the name servers' clients. When authoritative servers are sent queries for zones that they are not authoritative for, and they are configured as a non-caching server (as recommended), they can either be configured to return a referral to the root servers or they can be configured to refuse to answer the query. The recommendation is to configure authoritative servers to refuse to answer queries for any zones for which they are not authoritative. This is more efficient for the server and allows it to spend more of its resources doing what its intended purpose is, answering authoritatively for its zone.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> @@ -173,7 +173,7 @@ The exceptions are glue records supporting zone delegations, CNAME records suppo If resource records are maintained that resolve to a fully qualified domain name in another zone, and the usage is not for resource records resolving to hosts that are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms with a documented and approved mission need, this is a finding. - <VulnDiscussion>The use of CNAME records for exercises, tests, or zone-spanning aliases should be temporary (e.g., to facilitate a migration). When a host name is an alias for a record in another zone, an adversary has two points of attack: the zone in which the alias is defined and the zone authoritative for the alias's canonical name. This configuration also reduces the speed of client resolution because it requires a second lookup after obtaining the canonical name. Furthermore, in the case of an authoritative name server, this information is promulgated throughout the enterprise to caching servers and thus compounds the vulnerability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> + <VulnDiscussion>The use of CNAME records for exercises, tests, or zone-spanning (pointing to zones with lesser security) aliases should be temporary (e.g., to facilitate a migration) and not be in place for more than six months. When a host name is an alias for a record in another zone, an adversary has two points of attack: the zone in which the alias is defined and the zone authoritative for the alias's canonical name. This configuration also reduces the speed of client resolution because it requires a second lookup after obtaining the canonical name. Furthermore, in the case of an authoritative name server, this information is promulgated throughout the enterprise to caching servers and thus compounds the vulnerability.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls> False False @@ -190,7 +190,8 @@ Review the RRs to confirm that there are no CNAME records older than 6 months. The exceptions are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms. In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated (AO approval of use of a commercial cloud offering would satisfy this requirement). Additional exceptions are CNAME records in a multi-domain Active Directory environment pointing to hosts in other internal domains in the same multi-domain environment. -If there are zone-spanning CNAME records older than 6 months and the CNAME records resolve to anything other than fully qualified domain names for glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms with an AO-approved and documented mission need, this is a finding. +If there are zone-spanning (i.e., zones of lesser security)CNAME records older than 6 months and the CNAME records resolve to anything other than fully qualified domain names for glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms with an AO-approved and documented mission need, this is a finding. + <VulnDiscussion>Without configuring a local cache of revocation data, there is the potential to allow access to users who are no longer authorized (users with revoked certificates). @@ -274,7 +275,9 @@ The DNS server does not have the capability of shutting down or restarting the i False False - Notification to system administrator is not configurable in Windows 2012. In order for administrator to be notified if functionality of DNSSEC/TSIG has been removed or broken, the ISSO/ISSM/DNS administrator would need to implement a third-party monitoring system. At a minimum, the ISSO/ISSM/DNS administrator should have a documented procedure in place to review the diagnostic logs on a routine basis every day. + Note: If only zones hosted are AD-integrated zones, this check is not applicable. + +Notification to system administrator is not configurable in Windows 2012. In order for administrator to be notified if functionality of DNSSEC/TSIG has been removed or broken, the ISSO/ISSM/DNS administrator would need to implement a third-party monitoring system. At a minimum, the ISSO/ISSM/DNS administrator should have a documented procedure in place to review the diagnostic logs on a routine basis every day. If a third-party monitoring system is not in place to detect and notify the ISSO/ISSM/DNS administrator if functionality of DNSSEC/TSIG has been removed or broken and the ISSO/ISSM/DNS administrator does not have a documented procedure in place to review the diagnostic logs on a routine basis every day, this is a finding. @@ -355,6 +358,8 @@ EnableLoggingForTombstoneEvent EnableLoggingForZoneDataWriteEvent EnableLoggingForZoneLoadingEvent +Note: The UseSystemEventLog does not have to be set to true if all other variables are logged per the requirement and it can be validated that the events are being logged to a different log file destination. + If all required diagnostic events are not set to "True", this is a finding. @@ -2571,7 +2576,9 @@ If any other user or group has greater than READ permissions to the %ALLUSERSPRO HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters True ValueData is set to 255 which disables IPv6 - Log on to the DNS server using the Domain Admin or Enterprise Admin account. + Note: If the Windows 2012 DNS server is hosting IPv6 records, this requirement is not applicable. + +Log on to the DNS server using the Domain Admin or Enterprise Admin account. From a command prompt, run regedit. In the User Account Control dialog box, click Continue.