Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
From a command prompt, type net share and press enter. If any shares appear other than default administrative shares (e.g., C$, NETLOGON$), then this is a finding
The SA should disable all non-administrative shares.
BIND DNS zone record documentation will preferably reside in the zone file itself through comments, but if this is not feasible, the DNS database administrator will maintain a separate database for this purpose. The zone file location can be found by examining the named.conf and searching for the zone statement. Within the zone statement will be a file option that will display the name of the zone file. The reviewer should check that the record’s last verified date is less than one year prior to the date of the review. If this is not the case for any host or group of hosts, then this is a finding. Windows Ask the DNS database administrator if they maintain a separate database with record documentation. Windows DNS does not provide the capability to insert comments for records in a zone. The reviewer should check that the record’s last verified date is less than one year prior to the date of the review. If this is not the case for any host or group of hosts, then this is a finding.
Working with DNS Administrators and other appropriate technical personnel, the IAO should attempt to validate the hosts with expired validation dates. If these cannot be validated within a reasonable period of time, they should be removed. A zone file should contain adequate documentation that would allow an IAO or newly assigned administrator to quickly learn the scope and structure of that zone. In particular, each record (or related set of records, such as a group of LAN workstations) should be accompanied by a notation of the date the record was created, modified, or validated and record the owner’s name, title, and organizational affiliation. The owner of a record is an individual with the authority to request that the record be modified or deleted.
Review the zone files and confirm with the DNS administrator that the hosts defined in the zone files do not reside in another zone with its fully qualified domain name. If extraneous resource records are maintained, then this is a finding. BIND The zone file location can be found by examining the named.conf and searching for the zone statement. Within the zone statement will be a file option that will display the name of the zone file. Review the zone file and check for records that contain domain names outside of the zone. I.E. A zone named fso.chambersburg.com will not have a record for a host with a domain ending in disa.mil. 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. 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. Windows Open the DNS management snap in for the Administrative Tools menu. Expand the Forward Lookup Zones folder. Expand each zone and ensure the name column for each record does not contain a name for a record that resides outside of the zone. I.E. A zone named fso.chambersburg.com will not have a record for a host with a domain ending in disa.mil. 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. 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.
The DNS database administrator should remove any resource records for a host in a zone file if its fully qualified domain name resides in another zone, unless the record is a glue record or temporary CNAME record supporting a system migration.
BIND The zone file location can be found by examining the named.conf and searching for the zone statement. Within the zone statement will be a file option that will display the name of the zone file. The record type column will display CNAME. This is usually the third or fourth field in a record depending if the TTL value is utilized. Without a TTL value, the CNAME type will be in the third field, otherwise it will display as the fourth field. Review the zone files and the DNS zone record documentation to confirm that there are no CNAME records, pointing to a zone with lesser security, 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. 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. Windows Open the DNS management snap in for the Administrative Tools menu. Expand the Forward Lookup Zones folder. Review the type column for each record to locate those with a type of Alias (CNAME). Ask the DNS administrator to see the database with the record documentation is stored to confirm there are not CNAME records, pointing to a zone with lesser security, 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. 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.
The DNS database administrator should remove any zone-spanning CNAME records that have been active for more than six months.
BIND The zone file location can be found by examining the named.conf and searching for the zone statement. Within the zone statement will be a file option that will display the name of the zone file. Review the zone files, and confirm with the DNS administrator that each NS record points to an active name server authoritative for the domain, it this is not the case, then this is a finding. Windows Open the DNS management snap in for the Administrative Tools menu. Expand the Forward Lookup Zones folder. Review the type column for each record to locate those with a type of Name Server (NS). Confirm with the DNS administrator that each NS record points to an active name server authoritative for the domain, it this is not the case, then this is a finding.
The DNS database administrator should remove any NS records in a zone file that do not point to an active name server authoritative for the domain specified in that record.
During the initial interviews, the reviewer may have already identified that a name server is supporting production services other than DNS. At this point, the reviewer should validate that response through a hands-on check of the actual name server. UNIX The only permitted services to be running on a DNS UNIX BIND server are those implementing: - DNS - Secure shell - Host intrusion detection - Host file integrity - Network management or monitoring - Anti-virus - Backup - UPS - NTP The below are not permitted: Services started through inetd.conf: admind, chargen, echo, etherstatd, fingerd, ftpd, httpd, ICQ server, identd, netstat, netstatd, nit, nntp, nsed, nsemntd, pfilt, portd, quaked, rexd, rexecd, rje_mapper, rlogind, rpc_3270, rpc_alias, rpc_database, rpc_keyserv, rpc_sched, rquotad, rsh, rstatd, rusersd, selectd, serverd, showfhd, sprayd, statmon, sunlink_mapper, sysstat, talkd, telnetd, tfsd, tftpd, timed, ttdb, ugidd, uucpd, and walld. Services started at boot time: NFS client, NFS server process and SNMP daemon, automounter, printer queue daemon, and RPC portmapper. (For Solaris, disable the following scripts in rc2.d: S73nfs.client, S74autofs, S80lp, S71rpc, and S99dtlogin and the following scripts in rc3.d: S15nfs.server and S76snmpd.) Instruction: In the presence of the reviewer, the SA should enter the following command: ps –ef Based on the command output, the reviewer should be able to determine if the machine is dedicated to DNS or if it is supporting other production services. If additional services are running and it is determined the name server is not running on dedicated hardware, then this is a finding.
Working with DNS and Systems Administrators, the IAO should migrate the DNS software to dedicated hardware for the purpose of supporting the name server or remove/migrate any additional programs or applications, running on the name server to ensure the name server is running on dedicated hardware.
UNIX Instruction: The reviewer must work with the SA to obtain the user name running the named process. In the presence of the reviewer, the SA should enter the following command to obtain the owner of the named process: ps –ef | grep named The location to the encryption keys can be found by examining the keys directive in the /etc/named.conf file. In the presence of the reviewer, the SA should enter the following command while in the directory containing the DNS encryption keys: ls –la ‘encryption_key_file’ If the DNS encryption key files have permissions weaker than 640, then this is a finding. Windows with BIND Instruction: The reviewer must work with the SA to obtain the owner of the named.exe. In the presence of the reviewer, the SA should right-click on the named.exe file and select Properties | Security tab | Advanced | Owner tab. For each DNS encryption key file listed in c:\named\etc\named.conf keys directive , right-click on the file and select Properties | Security tab. If the DNS encryption key files have permissions that allow read access to anyone beyond the owner of the named.exe, then this is a finding.
The SA should modify permissions of the files containing DNS encryption keys so that only the DNS software process ID (PID) has read access to these files.
UNIX Instruction: The reviewer must work with the SA to obtain the username and groupname of the DNS database administrator, DNS software administrator, and the username running the named daemon process. In the presence of the reviewer, the SA should enter the following command to obtain the owner of the named process: ps –ef | grep named There are different ways (e.g., password/group file, NIS+, etc.) to obtain the DNS database administrator’s username and groupname, the reviewer is to work with the SA to obtain this information based on the configuration of the site’s UNIX OS. The zone files can be located by viewing the named.conf configuration for the zone statement and the file directive contained within the zone statement. In the presence of the reviewer, the SA should enter the following command while in the directory containing the zone files: ls -l If the zone files have permissions that allow write access to anyone beyond the owner of the named process or the DNS database administrator then this is a finding. Windows Instruction: The reviewer must obtain the username and groupname of the DNS database administrator. The reviewer must work with the SA to obtain the owner of the named.exe or dns.exe program. In the presence of the reviewer, the SA should right-click on the named.exe or dns.exe file and select Properties | Security tab | Advanced | Owner tab. For each Standard or Primary zone file, right-click on the file in %SystemRoot%\System32\Dns and select Properties | Security tab. If the zone files have permissions that allow write access to anyone beyond Administrators, Enterprise Domain Controllers, Enterprise Admins, Domain Admins, System or DNS Admins, then this is a finding. For Active directory integrated zones, the permissions of the Active Directory database should be verified. They usually reside in %SystemRoot%\NTDS\ntds.dit The permissions should only give full control access to System, Administrators, Creator Owner, and Local Service. Any others, then this is a finding.
The SA should modify permissions of zone files that only the DNS software PID and/or the DNS database administrator have edit access to the zone database files.
UNIX Instruction: The reviewer must work with the SA to obtain the username and groupname of the DNS software administrator and the username running the named daemon process. In the presence of the reviewer, the SA should enter the following command to obtain the owner of the named process: ps –ef | grep named There are different ways (i.e., password/group file, NIS+, etc.) to obtain the DNS software administrator’s username and groupname, the reviewer is to work with the SA to obtain this information based on the configuration of the site’s UNIX OS. In the presence of the reviewer, the SA should enter the following command while in the directory containing the DNS configuration files: ls –l /etc/named.conf If the DNS configuration files have permissions that allow write access to anyone beyond the DNS software administrator or the DNS software administrator then this is a finding. Windows For ISC BIND: Instruction: The reviewer must work with the SA to obtain the username and groupname of the DNS software administrator and the owner of the named.exe or dns.exe or dns.exe program. In the presence of the reviewer, the SA should right-click on the named.exe or dns.exe file and select Properties | Security tab | Advanced | Owner tab. The reviewer should ask the SA for the location of the ISC BIND named.conf/zone files. For each DNS configuration file, right-click on the file and select Properties | Security tab. If the DNS configuration files have permissions that allow write access to anyone beyond the DNS software administrator then this is a finding. For Windows DNS: Open the DNS management console and expand the Forward Lookup Zones. Right click on each zone and select Properties. Select the Security tab. In order to accommodate Secure Dynamic Updates the “Authenticated Users” group must have Create/Delete Child objects permission. If the DNS configuration files have permissions that allow write access to anyone beyond the DNS software administrator or permissions other than those needed to accommodate Secure Dynamic Updates, then this is a finding.
The SA should modify permissions of the DNS name server configuration files so that only the DNS software administrator and the DNS software PID have write access to the DNS software configuration files. The SA should modify permission to the DNS configuration files to allow “Authenticated Users” to have Create/Delete Child Object permission to support Secure Dynamic Updates. The SA should modify permission to limit all other write access to the DNS configuration files to only the DNS software administrator.
UNIX Instruction: In the presence of the reviewer, the SA should enter the following command to verify the IP address is not obtained by DHCP, hme0 is used as an example, please confirm the interface: ifconfig hme0 auto_dhcp status If “Ifconfig: hme0: interface is not under DHCP control,” is not displayed, then this is a finding. Please note this above mentioned command does not work on every version of UNIX, if this command does not work, please use the below instruction. In the presence of the reviewer, the SA enters the following command while in the /etc directory: The reviewer should ensure the file /etc/dhpc.hme0 is not located on the server. ls -l If the file dhcp.hme0 is listed (interface designation may different), then this is a finding. Windows Instruction: In the presence of the reviewer, the SA should select Start | Run, this will bring up the “Run” dialog box. Type cmd at the command line, this will bring up the command screen. Enter the following command: ipconfig /all If “DHCP Enabled” is not set to “No,” then this is a finding.
The SA should configure the name server with an IP address that is statically defined.
UNIX Instruction: The reviewer must work with the SA to obtain the program name. In the presence of the reviewer, the SA should enter the following command to confirm the integrity checking tool is installed and running: ps –ef | grep process name If an integrity checking tool is not installed and running, then this is a finding. With the assistance of the SA, confirm that the integrity checking tool is monitoring for any modifications to the root hints and name server’s configuration (e.g., named.conf), if this is not the case, then this is a finding. If using ISC BIND name server software, common names for the root hints file are root.hints, named.cache, or db.cache. The name is configurable within the named.conf file. rndc.conf will be protected in the same manner. Windows Instruction: The reviewer must work with the SA to obtain the service name. Instruction: The reviewer should examine the Windows Services GUI to identify started services (in Windows 2000/2003, right click on “My Computer” and select “Manage”. In the left windowpane, click on “Services and Applications”. A list of services is displayed in the right windowpane. Click on the “Status” column heading to sort by status. The started services will be grouped together). Also check the “Applications” tab of “Task Manager” for applications that do not run as a service (Simultaneously press Ctrl-Alt-Del keys and select the “Applications” tab). The reviewer should be able to determine if an integrity checking tool is installed and running. If an integrity checking tool is not installed and running, then this is a finding. With the assistance of the SA, confirm that the integrity checking tool is monitoring for any modifications to the root hints, which can be found C:/Windows/System32/DNS/cache.dns. In addition ensure the tool is checking the zone files. Active directory zone files are stored in the active directory database. The database can be found using the windows search feature and locating the ntds.dit file which is the database. For non-active directory zones, obtain the name of the zone from the DNS management console list of forward zones. Enter the zone name into the windows search and it will display the path to the actual zone files, normally found in a backup directory.
The SA should install an integrity checking tool on the name server and configure the tool to monitor for any modifications to the root.hints and name server configuration files.
BIND Instruction: The reviewer should review the configuration files and check each zone statement for the presence of the allow-update phrase, which enables cryptographically authenticated dynamic updates: The reviewer should identify the allow-update phrase. The following example disables dynamic updates: allow-update {none;}; In addition, the absence of the allow-update clause will deny updates by default. If dynamic updates are not disabled, as shown in the above example, they must be cryptographically authenticated as shown in the below example. The following example demonstrates cryptographically authenticated dynamic updates: allow-update {key ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil; }; If dynamic updates are not disabled or cryptographically authenticated, then this is a finding. Windows 2000/2003 DNS Instruction: In the presence of the reviewer, the SA must review the “Properties” dialog box, select the “General” tab, and check to see if dynamic updates are allowed. If dynamic updates are enabled, ensure that “Only secure updates” has been selected. If this is not the case, then this is a finding.
For BIND implementations, the DNS software administrator must ensure that each zone statement in named.conf contains the phrase allow update{none;}; to disable dynamic updates or allow-update {key ks1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil;}; (this is an example key name) to encrypt dynamic updates. For Windows 2000 DNS, disable dynamic updates or if dynamic updates are allowed via the General tab within the Properties dialog box, the DNS software administrator should select Only secure updates. In cases in which the name server is not running BIND or Windows 2000 DNS, the DNS software administrator must determine how to disable dynamic updates or encrypt them. If this is not possible, then the product must be replaced as soon as it is feasible to do so.
BIND Instruction: This check is only applicable to slave servers. If there is not an allow-transfer phrase within the zone statement, then this is a CAT I finding. If there is an allow-transfer statement, there must be a TSIG key corresponding to each of the zone partners. The reviewer can validate this by examining the key and server statements within named.conf. Check the keys phrase within each of the server statements. Verify the key statement is configured to cryptographically authenticate the master name server; an example is provided below, if this is not configured, then this is a finding. On the master name server, this is an example of a configured key statement: key ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil. { algorithm hmac-md5; include "/etc/dns/keys/tsig-example.key"; }; zone “disa.mil” { type master;file “db.disa.mil”; allow-transfer { key ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil.; }; }; On the slave name server, this is an example of a configured key statement: key ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil. { algorithm hmac-,d5; include "/etc/dns/keys/tsig-example.key"; }; server 10.2.2.2 { keys {ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil}; }; zone “disa.mil” { type slave; masters { 10.1.1.1; }; file “db.disa.mil”; }; A violation of this requirement can have one of two severity levels depending upon the extent of the violation. If slaves do not authenticate master servers in any manner, then the discrepancy would be a Category I finding. If some form of authentication exists (i.e., based on IP address), but it is not based on cryptography, then the discrepancy would be a Category II finding. Windows 2000/2003 DNS: Instruction: This check only applies if the name server is not active directory integrated. If the Windows DNS zone type is not active directory integrated, then the open the DNS management console snap-in, right click on the zone and select properties. If name servers tab has entries, then this will still be a CAT II finding. If the name servers tab does not have entries, then this is a CAT I. In cases in which the name server is not running BIND or Windows DNS, the reviewer must still examine the configuration and its documentation to validate this requirement. Mitigation: A violation of this requirement can have one of two severity levels depending upon the extent of the violation. If slaves do not authenticate masters in any manner, then the discrepancy would be a Category I finding. If some form of authentication exists (i.e., based on IP address), but it is not based on cryptography, then the discrepancy would be a Category II finding.
The DNS software administrator should configure each slave supporting a zone to cryptographically authenticate its master before accepting zone updates.
BIND Instruction: This check is only applicable to zone master servers. If there are no allow-transfer phrases within named.conf, then this is a finding. If there are allow-transfer phrases, then check that there is one corresponding to each of the zone partners. If this is not the case, then this is also a finding. If there are allow-transfer phrases for servers other than those supplied, then there may be a finding associated with the incompleteness of the list. If the key statement references a file, then no other key statement should reference the same file. If the key statement includes a character representation of the key itself (an improper configuration), then no other key statement should include the same character string. On the master name server, this is an example of a configured allow-transfer phrase: zone “disa.mil” { type master; file “db.disa.mil”; allow-transfer {10.10.10.1; key ns1.kalamazoo.disa.mil_ns2.kalamazoo.disa.mil.; }; }; Windows 2000/2003 DNS This check only applies for Windows DNS zones not integrated with active directory. From the DNS management console snap-in, expand the Forward Lookup zones branch, select the zone you want to configure and right click and select Properties. Select the Zone Transfer tab. If “Allow zone transfers:” is checked, “Only to the following servers” must also be checked. The reviewer must validate the name servers listed. If this is not the case, then this is a finding
The DNS software administrator should configure each zone master server to limit zone transfers to a list of active slaves authoritative for that zone. Configuration details may be found in the DNS STIG Section 4.2.8.
BIND Instruction: If all of a zone’s NS records are valid, then the default behavior in BIND complies with this requirement and does not require the DNS software administrator to take any additional action. In some cases, the DNS software administrator must implement a non-default configuration to comply with operation requirements. If this is the case, the DNS software administrator must have an understanding of the named.conf options that govern how master name servers notify other hosts of zone changes and when slave servers will accept notifications. If none of these options are selected, the resulting behavior represents an acceptable security risk. If these phrases are configured, then this is a finding. The phrases within the options statement that govern this behavior are: - notify – which turns notification on or off (defaults to on) - allow-notify – which defines from which servers a slave will accept notifications (defaults to the master name server only) Windows DNS Instruction: This check is not applicable to those Windows DNS Zones that are active directory integrated. Those zones will be replicated through active directory. For those servers running as a standard secondary zone, verify the name servers listed are only those authoritative for the zone. From the DNS management console snap-in, expand the Forward Lookup zones branch, select the zone you want to configure and right click and select Properties. Verify the entries under the Name Servers tab are only those authoritative for the zone. In cases in which the name server is not running BIND or Windows DNS, the reviewer must still examine the configuration and its documentation to validate this requirement.
The DNS software administrator should configure a name server to only accept notifications of zone changes from a host authoritative for that zone. Configuration details may be found in the DNS STIG.
BIND The reviewer should identify the recursion and allow-query phrases. They should look as follows: Options { recursion no; allow-query {none;}; }; Zone “example.com” { Type master; File “db.example.com”; Allow-query { address_match_list }; }; If either of these phrases is missing or have a value other than what is listed above, then this is a finding. Windows 2003 DNS Instruction: This check only applies if the name server is a master name server, the Windows DNS servers are to only be configured as master name servers. Open the DNS management console snap-in. Right click on the server and select properties. If available, under the forwarders tab ensure enable forwarders is not selected. If “Enable forwarders” is checked, this constitutes a finding. Also examine the “Advanced” tab of the DNS server “Properties” dialog box. If “Disable recursion” is not checked, then this is a finding.
The DNS Administrator should configure the authoritative name server to prohibit recursion. Configuration details may be found in the DNS STIG.
BIND Instruction: This check is only applicable to caching name servers. Verify the allow-query and allow-recursion phrases are properly configured. The reviewer should identify the allow-query and allow-recursion phrases. It should look as follows: allow-query {trustworthy_hosts;}; allow-recursion {trustworthy_hosts;}; The name of the ACL does not need to be “trustworthy_hosts” but the name should match the ACL name defined earlier in named.conf for this purpose. If not, then this is a finding. The reviewer will also check for whether non-internal IP addresses appear in either the referenced ACL (e.g., trustworthy_hosts) or directly in the statements themselves. If non-internal IP addresses do appear, then this is a finding. Windows 2000/2003 DNS Instruction: Windows 2000/2003 DNS should not be deployed as a caching name server. Consequently, the use of forwarders and recursion is prohibited on Windows DNS. The reviewer will validate that the "Disable recursion" and the “Secure cache against pollution" on the “Advanced” tab of the name server properties are selected. Examine the “Advanced” tab of the DNS Server “Properties” dialog box. If “Disable recursion” and “Secure cache against pollution” is not checked, then this is a finding. The reviewer will also validate, if available, that the "Enable forwarders" on the “Forwarders” tab of the name server properties is not selected. Examine the “Forwarders” tab of the DNS Server “Properties” dialog box. If “Enable forwarders” is checked, then this is a finding. In cases in which the name server is not running BIND or Windows 2000/2003 DNS, the reviewer must still examine the configuration and its documentation to validate this requirement.
The DNS software administrator should configure the caching name server to accept recursive queries only from the IP addresses and address ranges of known supported. Configuration details for BIND and Windows DNS may be found in the DNS STIG.
The default level for logging was modified in BIND version 9.7. Starting at that version logging is set to debugging level by default. Therefore, if the logging statement is missing AND the version is 9.7 or more recent, this is NOT a finding. For a BIND configuration for versions before 9.7, if a logging statement is present, it will have the form: logging { channel channel_name file path_name | syslog syslog_facility severity (critical | error | warning | notice | info | debug [level]| dynamic);] print-severity yes/no; print-time yes/no; }; category category_name { channel_name ; [ channel_name ; … }; }; Instruction: If a logging statement is not present and the BIND version is prior to 9.7, then this is a finding. The reviewer will look at the severity clause in each of the channel phrases of the logging statement. It should read either notice, info or debug for each defined channel (although debug would not typically appear unless the review is concurrent with a troubleshooting effort). If the logging statement is not properly configured, then this is a finding. NOTE: Debug level may cause operational issues due to log file sizes and is therefore not a requirement for anything other than troubleshooting purposes. Windows DNS Instruction: For a Windows 2003 DNS configuration: On the “Logging Tab” or “Debug Logging” tab of the “DNS Server Properties” dialog box, if “Log Packets for “Notify” and “Update” are not checked, then this is a finding. Mitigation: A violation of this requirement can have one of two severity levels depending upon the extent of the violation. If no logging exists, then the discrepancy would be a Category I finding. If some logging exists, but not for all of the events listed, then the discrepancy would be a Category II finding.
The DNS software administrator will configure the DNS software to log, at a minimum, success and failure of the following events: - start and stop of the name server service or daemon - zone transfers - zone update notifications - dynamic updates
DNS software administrators need DNS transaction logs for a wide variety of reasons including troubleshooting, intrusion detection, and forensics. These logs should be appropriately secured, having file permissions that restrict unauthorized changes or viewing, and archived, being appropriately backed-up and stored so that they can be examined at a future time. BIND The DNS software administrator will configure the DNS software to send all log data to either the system logging facility (e.g., UNIX syslog or Windows Application Event Log) or an alternative logging facility with security configuration equivalent to or more restrictive than the system logging facility. Instruction: On an examination of the DNS configuration file (if BIND, named.conf), the reviewer can determine whether log data is sent to a facility other than the system logging facility. If this is the case, then the reviewer should do the following at a minimum: - Compare the file permissions of the operating system logs with the file permissions of the alternative logging facility for DNS (e.g., using ls –l). If the permissions on the alternative are weaker in any manner, this constitutes a finding. - Determine whether the system logs are transferred or copied to media on another machine (e.g., a cron job that periodically moves logs to another computer). If this is the case and there is not a similar technology in place for the DNS logs, then this constitutes a finding. The reviewer can identify other ways in which the security of the DNS logs may be weaker than the security of the system logs, and can generate a finding based on that discovery so long as the explanation of the weakness is clearly documented in the SRR results. Windows DNS Windows DNS software log files will be equivalent to the system logging facility by default. In addition, the DNS debug log file should be checked at %systemroot%\system32\dns\dns.log. The permissions should be restricted to the Administrators and/or Auditors group (in accordance with the Windows STIG permission settings for Windows Event Log settings) on the local computer or the Domain Admins group. In cases in which the name server is not running BIND or Windows DNS, the reviewer must still examine the configuration and its documentation to validate this requirement.
The DNS software administrator should either configure named.conf to utilize the system logging facility or place additional technical controls (e.g., more restrictive file permissions) on the alternative logging facility so that it is as least as secure as the system logging facility.
BIND Instruction: Based on the logging statement in named.conf, the reviewer can determine where the DNS logs are located. If there logging is not configured, then this is a finding. These logs (which in many cases are likely to be the system logs), should be viewed using the UNIX cat or tail commands, a text editor, or – in the case of Windows – the “Event Viewer.” When examining the logs, the reviewer should ensure that entries have timestamps and severity codes. If timestamps and severity codes are not found on one or more entries, then this is a finding. logging { channel channel_name file path_name | syslog syslog_facility severity (critical | error | warning | notice | info | debug [level]| dynamic);] print-severity yes/no; print-time yes/no; }; category category_name { channel_name ; [ channel_name ; … }; }; Instruction: If the DNS entries in the logs do not note their severity (i.e., critical, error, warning, notice, or info), then this constitutes a finding. Windows DNS Windows DNS software adds timestamps and severity information by default. In cases in which the name server is not running BIND or Windows DNS, the reviewer must still examine the configuration and its documentation to validate this requirement.
The DNS software administrator should configure the DNS software to add timestamps and severity information to each entry in all logs. Configuration details for BIND may be found in the DNS STIG Section 4.2.5.
BIND Instruction: This check only applies if the name server is an authoritative name server. Ensure there is not a root hints on the name server. Common names for the root hints file are root.hints, named.cache, or db.cache. The name is configurable within the named.conf file. Windows DNS This check only applies if the name server is an authoritative name server. For a Windows 2000/2003 DNS configuration: Select the “Root Hints” Tab of the “DNS Server Properties” dialog box, ensure the root name server entries have been removed. To remove entries, right click the entry and click the “Remove” button.
The SA should remove the root hints file. For a BIND installation, the SA should remove the root hints file. Common names for the root hints file are root.hints, named.cache, or db.cache. The name is configurable within the named.conf file. For a Windows 2000/2003 DNS configuration, the SA should: Select the Root Hints Tab of the DNS Server Properties dialog box, to remove entries, right click the entry and click the Remove button.
Log in to the server with an account that has admin rights. Right-click “My Computer” on the desktop and click “Manage.” This brings up the “Computer Management” tool. Click the plus sign next to “Services and Applications” on the left pane to expand it. Select “Services” on the left panel. On the right pane, scroll down and select “DHCP Server.” Right-click “DHCP Server” and click “Properties.” This brings up the “DCHP Server Properties”. The reviewer will validate the DHCP server service is disabled. The “Disabled” drop down selection is to be selected on the “General” tab of the “DHCP Server Properties.” If the DHCP server service is not disabled, then this is a finding.
Working with appropriate SA and technical personnel, the IAO should plan to migrate the DHCP service to another machine as soon as it is feasible to do so.
The reviewer will validate zone transfers are prohibited. The reviewer will ensure the "Allow zone transfers" check box is not selected on the “Zone Transfers” tab of the name server properties. If zone transfers are allowed, then this is a finding. Windows allows for two ways of synchronizing zone data across name servers: (1) traditional RFC-compliant DNS zone transfers; and (2) AD-replication. The latter only works when Windows DNS is integrated with AD, which makes each of the DNS records an AD object. The Windows 2000/2003 DNS implementation of traditional zone transfers does not meet the STIG requirement that the transfers be cryptographically authenticated using a technology such as TSIG. Fortunately, AD-replication is cryptographically authenticated. Therefore, the solution in a pure Windows 2000/2003 DNS implementation is to integrate DNS with AD and disable zone transfers
Working with relevant DNS administrators, the SA should configure Windows DNS to rely on Active Directory to replicate zone data whenever possible. If this is not feasible, then the SA must establish an IPSEC VPN between relevant zone partners or implement a satisfactory alternative encryption-based authentication technology.
Windows DNS should not be deployed as a caching name server. Consequently, the use of forwarders and recursion is prohibited on Windows 2000/2003 DNS. The reviewer will validate that the "Enable Forwarders" check box is not selected on the “Forwarders” tab of the name server properties. If forwarders are enabled, then this is a finding.
The SA should disable forwarding (on the Forwarders tab of the name servers properties dialog box).
The reviewer will validate the "Use WINS forward lookup" is not checked on the “WINS” tab on the properties dialog of each zone. If WINS is integrated on a Windows 2000 DNS server, then this is a finding.
The SA should disable any integration between DNS and WINS as soon as it feasible to do so. If WINS is required for legacy applications, then DNS clients will need to be reconfigured to use WINS rather than DNS for NetBIOS name resolution. The SA should uncheck Use WINS forward lookup on the WINS tab on the properties dialog of each zone.
Review the membership of the DNSUpdateProxy group to determine if any of the computer accounts are DHCP servers. If there are any computer accounts for DHCP servers, this is a finding. View Computer Management, Local Users and Groups, Groups. Review the membership of the DNSUpdateProxy group to determine if any of the accounts are DHCP servers.
The IAO will ensure computer accounts for DHCP servers are not members of the DNSUpdateProxy group.
BIND • Instruction: Examine all zone statements contained in the named.conf file for a line containing the word file designating the actual file that stores the zones records. Examine the file that contains zones records for any IPv6 addresses containing the prefixes “FE8”, “FE9”, “FEA”, or “FEB”. If any link-local scope addresses are found, then this is a finding. Windows DNS • Instruction: From the windows task bar, select Start, Programs/All Programs, Administrative Tools, DNS to open the DNS management console. Expand the Forward Lookup Zones folder. Expand each zone folder and examine the host record entries. The third column titled Data will display the IP. Verify this column does not contain any IP address that begin with the prefixes “FE8”, “FE9”, “FEA”, or “FEB”.
The SA should remove any link-local addresses and replace with appropriate Site-Local or Global scope addresses.
BIND • Instruction: Examine all zone statements contained in the named.conf file for a line containing the word file designating the actual file that stores the zones records. Examine the file that contains zones records and verify IPv6 and IPv4 resource records are not in the same file. If the records are found in the same file, then this is a finding. Windows DNS Instruction: From the Windows task bar, select Start, Programs/All Programs, Administrative Tools, DNS to open the DNS management console. Expand the Forward Lookup Zones folder. Expand each zone folder and examine the host record entries. The third column titled Data will display the IP. Verify this column does not contain both IPv4 and IPv6 addresses.
The SA should remove the IPv6 records from the IPv4 zone and create a second zone with all IPv6 records.
Windows •Instruction: Click Start, click All Programs, click Administrative Tools, and select DNS. Expand the Forward Lookup Zones folder. Expand each zone and check for IPv6 records. If all records are IPv4, then confirm IPv6 is not enabled on any of the lan interfaces with the following: -Click Start, click Control Panel, and the double-click Network Connections. -Right-click any local area connection, and then click Properties. -The display will contain, Microsoft TCP/IP version 6 with a check next to the item if IPv6 is installed.
The DNS administrator will uninstall IPv6 from any lan interface that is not hosting IPv6 AAAA records within its zones. The following steps should be followed to uninstall IPv6 on an interface: -Click Start, click Control Panel, and the double-click Network Connections. -Right-click any local area connection, and then click Properties. -The display will contain, Microsoft TCP/IP version 6 with a check next to the item if IPv6 is installed. -Select Microsoft TCP/IP version 6 and then click Uninstall. -Select Yes to confirm the removal. -Select Yes restart the computer for the new settings to take effect.