kriterion 0.0.1
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +7 -0
- data/.gitignore +2 -0
- data/.ruby-version +1 -0
- data/.travis.yml +5 -0
- data/Dockerfile +18 -0
- data/Gemfile +12 -0
- data/Gemfile.lock +62 -0
- data/LICENSE.txt +21 -0
- data/README.md +58 -0
- data/Rakefile +6 -0
- data/bin/setup +8 -0
- data/bin/update_stigs.rb +42 -0
- data/criterion.gemspec +31 -0
- data/docker-compose.yml +14 -0
- data/exe/kriterion +16 -0
- data/lib/kriterion.rb +16 -0
- data/lib/kriterion/api.rb +27 -0
- data/lib/kriterion/backend.rb +13 -0
- data/lib/kriterion/backend/mongodb.rb +235 -0
- data/lib/kriterion/cli.rb +28 -0
- data/lib/kriterion/cli/api.rb +35 -0
- data/lib/kriterion/cli/worker.rb +35 -0
- data/lib/kriterion/event.rb +36 -0
- data/lib/kriterion/item.rb +42 -0
- data/lib/kriterion/logs.rb +14 -0
- data/lib/kriterion/metrics.rb +22 -0
- data/lib/kriterion/object.rb +50 -0
- data/lib/kriterion/report.rb +69 -0
- data/lib/kriterion/resource.rb +60 -0
- data/lib/kriterion/section.rb +32 -0
- data/lib/kriterion/standard.rb +65 -0
- data/lib/kriterion/version.rb +3 -0
- data/lib/kriterion/worker.rb +280 -0
- data/standards/cis_red_hat_enterprise_linux_7.json +34 -0
- data/standards/stig_a10_networks_adc_alg.json +209 -0
- data/standards/stig_a10_networks_adc_ndm.json +233 -0
- data/standards/stig_active_directory_domain.json +257 -0
- data/standards/stig_active_directory_forest.json +41 -0
- data/standards/stig_active_directory_service_2003.json +173 -0
- data/standards/stig_active_directory_service_2008.json +167 -0
- data/standards/stig_adobe_acrobat_pro_xi.json +167 -0
- data/standards/stig_adobe_acrobat_reader_dc_classic_track.json +179 -0
- data/standards/stig_adobe_acrobat_reader_dc_continuous_track.json +179 -0
- data/standards/stig_adobe_coldfusion_11.json +611 -0
- data/standards/stig_airwatch_mdm.json +185 -0
- data/standards/stig_aix_5.3.json +3095 -0
- data/standards/stig_aix_6.1.json +3047 -0
- data/standards/stig_akamai_ksd_service_impact_level_2_alg.json +209 -0
- data/standards/stig_akamai_ksd_service_impact_level_2_ndm.json +155 -0
- data/standards/stig_android_2.2_dell.json +311 -0
- data/standards/stig_apache_2.2_serverwindows.json +347 -0
- data/standards/stig_apache_2.2_sitewindows_security_implementation_guide.json +179 -0
- data/standards/stig_apache_server_2.0unix.json +341 -0
- data/standards/stig_apache_server_2.0windows.json +341 -0
- data/standards/stig_apache_server_2.2unix.json +347 -0
- data/standards/stig_apache_server_2.2windows.json +347 -0
- data/standards/stig_apache_site_2.0unix.json +185 -0
- data/standards/stig_apache_site_2.0windows.json +179 -0
- data/standards/stig_apache_site_2.2unix.json +185 -0
- data/standards/stig_apache_site_2.2windows.json +179 -0
- data/standards/stig_apple_ios6.json +341 -0
- data/standards/stig_apple_ios_10.json +245 -0
- data/standards/stig_apple_ios_11.json +269 -0
- data/standards/stig_apple_ios_4_good_mobility_suite_interim_security_configuration_guide_iscg.json +257 -0
- data/standards/stig_apple_ios_5.json +329 -0
- data/standards/stig_apple_ios_6.json +335 -0
- data/standards/stig_apple_ios_6_interim_security_configuration_guide_iscg.json +371 -0
- data/standards/stig_apple_ios_7.json +185 -0
- data/standards/stig_apple_ios_8_interim_security_configuration_guide.json +251 -0
- data/standards/stig_apple_ios_9_interim_security_configuration_guide.json +245 -0
- data/standards/stig_apple_os_x_10.10_yosemite_workstation.json +851 -0
- data/standards/stig_apple_os_x_10.11.json +725 -0
- data/standards/stig_apple_os_x_10.12.json +737 -0
- data/standards/stig_apple_os_x_10.8_mountain_lion_workstation.json +1241 -0
- data/standards/stig_apple_os_x_10.9_mavericks_workstation.json +809 -0
- data/standards/stig_application_layer_gateway_alg_security_requirements_guide_srg.json +911 -0
- data/standards/stig_application_layer_gateway_security_requirements_guide.json +911 -0
- data/standards/stig_application_security_and_development.json +1745 -0
- data/standards/stig_application_security_and_development_checklist.json +959 -0
- data/standards/stig_application_security_requirements_guide.json +1961 -0
- data/standards/stig_application_server_security_requirements_guide.json +791 -0
- data/standards/stig_arcgisserver_10.3.json +143 -0
- data/standards/stig_arista_mls_dcs-7000_series_l2s.json +53 -0
- data/standards/stig_arista_mls_dcs-7000_series_ndm.json +197 -0
- data/standards/stig_arista_mls_dcs-7000_series_rtr.json +143 -0
- data/standards/stig_bind_9.x.json +431 -0
- data/standards/stig_bind_dns.json +317 -0
- data/standards/stig_blackberry_10.2.x_os.json +179 -0
- data/standards/stig_blackberry_10_os.json +227 -0
- data/standards/stig_blackberry_bes_12.3.x_mdm.json +65 -0
- data/standards/stig_blackberry_bes_12.5.x_mdm.json +65 -0
- data/standards/stig_blackberry_device_service_6.2.json +425 -0
- data/standards/stig_blackberry_enterprise_mobility_server_2.x.json +149 -0
- data/standards/stig_blackberry_enterprise_server,_part_1.json +35 -0
- data/standards/stig_blackberry_enterprise_server,_part_2.json +155 -0
- data/standards/stig_blackberry_enterprise_server,_part_3.json +647 -0
- data/standards/stig_blackberry_enterprise_server_version_5.x,_part_1.json +35 -0
- data/standards/stig_blackberry_enterprise_server_version_5.x,_part_2.json +155 -0
- data/standards/stig_blackberry_enterprise_server_version_5.x,_part_3.json +653 -0
- data/standards/stig_blackberry_enterprise_service_v10.1.x_blackberry_device_service.json +317 -0
- data/standards/stig_blackberry_enterprise_service_v10.2.x_blackberry_device_service.json +263 -0
- data/standards/stig_blackberry_handheld_device.json +125 -0
- data/standards/stig_blackberry_os_10.3.x.json +257 -0
- data/standards/stig_blackberry_os_7.x.json +107 -0
- data/standards/stig_blackberry_os_7.x.x.json +101 -0
- data/standards/stig_blackberry_os_version_5-7.json +107 -0
- data/standards/stig_blackberry_playbook.json +65 -0
- data/standards/stig_blackberry_playbook_os_nea_mode.json +65 -0
- data/standards/stig_blackberry_playbook_os_v2.1.json +197 -0
- data/standards/stig_blackberry_uem_12.7.json +59 -0
- data/standards/stig_bluetoothzigbee.json +35 -0
- data/standards/stig_ca_api_gateway_alg.json +497 -0
- data/standards/stig_cisco_css_dns.json +71 -0
- data/standards/stig_cisco_ios_xe_release_3_ndm.json +395 -0
- data/standards/stig_cisco_ios_xe_release_3_rtr.json +149 -0
- data/standards/stig_cmd_management_server_policy.json +53 -0
- data/standards/stig_commercial_mobile_device_cmd_policy.json +83 -0
- data/standards/stig_csfc_campus_wlan_policy_security_implementation_guide.json +95 -0
- data/standards/stig_database_security_requirements_guide.json +767 -0
- data/standards/stig_dbn-6300_idps.json +107 -0
- data/standards/stig_dbn-6300_ndm.json +359 -0
- data/standards/stig_defense_switched_network.json +683 -0
- data/standards/stig_defense_switched_network_dsn.json +653 -0
- data/standards/stig_desktop_applications_general.json +41 -0
- data/standards/stig_dns_policy.json +155 -0
- data/standards/stig_domain_name_system_dns_security_requirements_guide.json +599 -0
- data/standards/stig_draft_aix.json +3503 -0
- data/standards/stig_edb_postgres_advanced_server.json +665 -0
- data/standards/stig_email_services_policy.json +137 -0
- data/standards/stig_exchange_2010_client_access_server.json +179 -0
- data/standards/stig_exchange_2010_edge_transport_server.json +389 -0
- data/standards/stig_exchange_2010_hub_transport_server.json +269 -0
- data/standards/stig_exchange_2010_mailbox_server.json +209 -0
- data/standards/stig_f5_big-ip_access_policy_manager_11.x.json +149 -0
- data/standards/stig_f5_big-ip_advanced_firewall_manager_11.x.json +41 -0
- data/standards/stig_f5_big-ip_application_security_manager_11.x.json +89 -0
- data/standards/stig_f5_big-ip_device_management_11.x.json +467 -0
- data/standards/stig_f5_big-ip_local_traffic_manager_11.x.json +407 -0
- data/standards/stig_final_draft_general_wireless_policy.json +71 -0
- data/standards/stig_firewall.json +449 -0
- data/standards/stig_firewall_-_cisco.json +449 -0
- data/standards/stig_firewall_security_requirements_guide.json +257 -0
- data/standards/stig_forescout_counteract_alg.json +83 -0
- data/standards/stig_forescout_counteract_ndm.json +239 -0
- data/standards/stig_free_space_optics_device.json +143 -0
- data/standards/stig_general_mobile_device_policy_non-enterprise_activated.json +113 -0
- data/standards/stig_general_mobile_device_technical_non-enterprise_activated.json +59 -0
- data/standards/stig_general_purpose_operating_system_srg.json +1199 -0
- data/standards/stig_general_wireless_policy.json +71 -0
- data/standards/stig_good_mobility_suite_server_android_os.json +203 -0
- data/standards/stig_good_mobility_suite_server_apple_ios_4_interim_security_configuration_guide_iscg.json +209 -0
- data/standards/stig_good_mobility_suite_server_windows_phone_6.5.json +449 -0
- data/standards/stig_goodenterprise_8.x.json +401 -0
- data/standards/stig_google_chrome_browser.json +209 -0
- data/standards/stig_google_chrome_current_windows.json +215 -0
- data/standards/stig_google_chrome_draft.json +281 -0
- data/standards/stig_google_chrome_v23_windows.json +275 -0
- data/standards/stig_google_chrome_v24_windows.json +263 -0
- data/standards/stig_google_chrome_v24_windows_benchmark.json +227 -0
- data/standards/stig_google_search_appliance.json +209 -0
- data/standards/stig_harris_secnet_11_54.json +89 -0
- data/standards/stig_hp-ux_11.23.json +3215 -0
- data/standards/stig_hp-ux_11.31.json +3155 -0
- data/standards/stig_hp-ux_smse.json +431 -0
- data/standards/stig_hpe_3par_storeserv_3.2.x.json +131 -0
- data/standards/stig_ibm_datapower_alg.json +401 -0
- data/standards/stig_ibm_datapower_network_device_management.json +395 -0
- data/standards/stig_ibm_db2_v10.5_luw.json +575 -0
- data/standards/stig_ibm_hardware_management_console_hmc.json +221 -0
- data/standards/stig_ibm_hardware_management_console_hmc_policies.json +35 -0
- data/standards/stig_ibm_maas360_v2.3.x_mdm.json +59 -0
- data/standards/stig_ibm_zvm_using_ca_vm:secure.json +473 -0
- data/standards/stig_idps_security_requirements_guide_srg.json +1865 -0
- data/standards/stig_idsips.json +257 -0
- data/standards/stig_iis6_server.json +221 -0
- data/standards/stig_iis6_site.json +263 -0
- data/standards/stig_iis_7.0_web_server.json +155 -0
- data/standards/stig_iis_7.0_web_site.json +299 -0
- data/standards/stig_iis_8.5_server.json +293 -0
- data/standards/stig_iis_8.5_site.json +347 -0
- data/standards/stig_infoblox_7.x_dns.json +419 -0
- data/standards/stig_infrastructure_l3_switch.json +599 -0
- data/standards/stig_infrastructure_l3_switch_-_cisco.json +659 -0
- data/standards/stig_infrastructure_l3_switch_secure_technical_implementation_guide_-_cisco.json +659 -0
- data/standards/stig_infrastructure_router.json +479 -0
- data/standards/stig_infrastructure_router_-_cisco.json +539 -0
- data/standards/stig_infrastructure_router_-_juniper.json +485 -0
- data/standards/stig_infrastructure_router__cisco.json +539 -0
- data/standards/stig_infrastructure_router__juniper.json +485 -0
- data/standards/stig_internet_explorer_8.json +821 -0
- data/standards/stig_internet_explorer_9.json +815 -0
- data/standards/stig_intrusion_detection_and_prevention_systems_idps_security_requirements_guide.json +371 -0
- data/standards/stig_ipsec_vpn_gateway.json +521 -0
- data/standards/stig_java_runtime_environment_jre_6_unix.json +65 -0
- data/standards/stig_java_runtime_environment_jre_6_win7.json +65 -0
- data/standards/stig_java_runtime_environment_jre_6_windows_xp.json +77 -0
- data/standards/stig_java_runtime_environment_jre_6_winxp.json +65 -0
- data/standards/stig_java_runtime_environment_jre_7_unix.json +65 -0
- data/standards/stig_java_runtime_environment_jre_7_win7.json +65 -0
- data/standards/stig_java_runtime_environment_jre_7_winxp.json +65 -0
- data/standards/stig_java_runtime_environment_jre_version_6_unix.json +77 -0
- data/standards/stig_java_runtime_environment_jre_version_6_windows_7.json +77 -0
- data/standards/stig_java_runtime_environment_jre_version_6_windows_xp.json +65 -0
- data/standards/stig_java_runtime_environment_jre_version_7_unix.json +77 -0
- data/standards/stig_java_runtime_environment_jre_version_7_windows_7.json +77 -0
- data/standards/stig_java_runtime_environment_jre_version_7_winxp.json +77 -0
- data/standards/stig_java_runtime_environment_jre_version_8_unix.json +107 -0
- data/standards/stig_java_runtime_environment_jre_version_8_windows.json +107 -0
- data/standards/stig_jboss_eap_6.3.json +413 -0
- data/standards/stig_juniper_srx_sg_alg.json +155 -0
- data/standards/stig_juniper_srx_sg_idps.json +179 -0
- data/standards/stig_juniper_srx_sg_ndm.json +443 -0
- data/standards/stig_juniper_srx_sg_vpn.json +185 -0
- data/standards/stig_keyboard_video_and_mouse_switch.json +269 -0
- data/standards/stig_l3_kov-26_talon_wireless_role.json +77 -0
- data/standards/stig_layer_2_switch.json +347 -0
- data/standards/stig_layer_2_switch_-_cisco.json +365 -0
- data/standards/stig_lg_android_5.x_interim_security_configuration_guide.json +245 -0
- data/standards/stig_lg_android_6.x.json +281 -0
- data/standards/stig_mac_osx_10.6_workstation.json +1319 -0
- data/standards/stig_mac_osx_10.6_workstation_draft.json +1319 -0
- data/standards/stig_mainframe_product_security_requirements_guide.json +1115 -0
- data/standards/stig_mcafee_application_control_7.x.json +203 -0
- data/standards/stig_mcafee_move_2.63.6.1_multi-platform_client.json +149 -0
- data/standards/stig_mcafee_move_2.63.6.1_multi-platform_oss.json +101 -0
- data/standards/stig_mcafee_move_2.6_multi-platform_client.json +149 -0
- data/standards/stig_mcafee_move_2.6_multi-platform_oss.json +101 -0
- data/standards/stig_mcafee_move_3.6.1_multi-platform_client.json +149 -0
- data/standards/stig_mcafee_move_3.6.1_multi-platform_oss.json +101 -0
- data/standards/stig_mcafee_move_agentless_3.03.6.1_security_virtual_appliance.json +167 -0
- data/standards/stig_mcafee_move_agentless_3.0_security_virtual_appliance.json +167 -0
- data/standards/stig_mcafee_move_agentless_3.0_vsel_1.9sva.json +203 -0
- data/standards/stig_mcafee_move_agentless_3.6.1_security_virtual_appliance.json +167 -0
- data/standards/stig_mcafee_move_av_agentless_4.5.json +155 -0
- data/standards/stig_mcafee_move_av_multi-platform_4.5.json +215 -0
- data/standards/stig_mcafee_virusscan_8.8_local_client.json +533 -0
- data/standards/stig_mcafee_virusscan_8.8_managed_client.json +533 -0
- data/standards/stig_mcafee_vsel_1.92.0_local_client.json +245 -0
- data/standards/stig_mcafee_vsel_1.92.0_managed_client.json +239 -0
- data/standards/stig_mdm_server_policy.json +47 -0
- data/standards/stig_microsoft_access_2003.json +47 -0
- data/standards/stig_microsoft_access_2007.json +77 -0
- data/standards/stig_microsoft_access_2010.json +119 -0
- data/standards/stig_microsoft_access_2013.json +113 -0
- data/standards/stig_microsoft_access_2016.json +107 -0
- data/standards/stig_microsoft_dot_net_framework_4.0.json +101 -0
- data/standards/stig_microsoft_excel_2003.json +47 -0
- data/standards/stig_microsoft_excel_2007.json +155 -0
- data/standards/stig_microsoft_excel_2010.json +287 -0
- data/standards/stig_microsoft_excel_2013.json +293 -0
- data/standards/stig_microsoft_excel_2016.json +257 -0
- data/standards/stig_microsoft_exchange_2010_client_access_server_role.json +71 -0
- data/standards/stig_microsoft_exchange_2010_core_server.json +47 -0
- data/standards/stig_microsoft_exchange_2010_edge_transport_server_role.json +233 -0
- data/standards/stig_microsoft_exchange_2010_hub_transport_server_role.json +125 -0
- data/standards/stig_microsoft_exchange_2010_mailbox_server_role.json +107 -0
- data/standards/stig_microsoft_exchange_server_2003.json +647 -0
- data/standards/stig_microsoft_groove_2013.json +71 -0
- data/standards/stig_microsoft_ie_version_6.json +599 -0
- data/standards/stig_microsoft_ie_version_7.json +749 -0
- data/standards/stig_microsoft_infopath_2003.json +41 -0
- data/standards/stig_microsoft_infopath_2007.json +167 -0
- data/standards/stig_microsoft_infopath_2010.json +155 -0
- data/standards/stig_microsoft_infopath_2013.json +149 -0
- data/standards/stig_microsoft_internet_explorer_10.json +857 -0
- data/standards/stig_microsoft_internet_explorer_11.json +839 -0
- data/standards/stig_microsoft_internet_explorer_9.json +821 -0
- data/standards/stig_microsoft_lync_2013.json +29 -0
- data/standards/stig_microsoft_office_system_2007.json +221 -0
- data/standards/stig_microsoft_office_system_2010.json +233 -0
- data/standards/stig_microsoft_office_system_2013.json +293 -0
- data/standards/stig_microsoft_office_system_2016.json +131 -0
- data/standards/stig_microsoft_onedrivebusiness_2016.json +89 -0
- data/standards/stig_microsoft_onenote_2010.json +77 -0
- data/standards/stig_microsoft_onenote_2013.json +71 -0
- data/standards/stig_microsoft_onenote_2016.json +71 -0
- data/standards/stig_microsoft_outlook_2003.json +65 -0
- data/standards/stig_microsoft_outlook_2007.json +479 -0
- data/standards/stig_microsoft_outlook_2010.json +515 -0
- data/standards/stig_microsoft_outlook_2013.json +497 -0
- data/standards/stig_microsoft_outlook_2016.json +359 -0
- data/standards/stig_microsoft_powerpoint_2003.json +47 -0
- data/standards/stig_microsoft_powerpoint_2007.json +131 -0
- data/standards/stig_microsoft_powerpoint_2010.json +191 -0
- data/standards/stig_microsoft_powerpoint_2013.json +251 -0
- data/standards/stig_microsoft_powerpoint_2016.json +233 -0
- data/standards/stig_microsoft_project_2010.json +83 -0
- data/standards/stig_microsoft_project_2013.json +95 -0
- data/standards/stig_microsoft_project_2016.json +95 -0
- data/standards/stig_microsoft_publisher_2010.json +107 -0
- data/standards/stig_microsoft_publisher_2013.json +101 -0
- data/standards/stig_microsoft_publisher_2016.json +101 -0
- data/standards/stig_microsoft_sharepoint_designer_2013.json +71 -0
- data/standards/stig_microsoft_skypebusiness_2016.json +29 -0
- data/standards/stig_microsoft_sql_server_2005_database.json +167 -0
- data/standards/stig_microsoft_sql_server_2005_instance.json +1001 -0
- data/standards/stig_microsoft_sql_server_2012_database.json +179 -0
- data/standards/stig_microsoft_sql_server_2012_database_instance.json +929 -0
- data/standards/stig_microsoft_visio_2013.json +89 -0
- data/standards/stig_microsoft_visio_2016.json +89 -0
- data/standards/stig_microsoft_windows_10_mobile.json +215 -0
- data/standards/stig_microsoft_windows_2008_server_domain_name_system.json +269 -0
- data/standards/stig_microsoft_windows_2012_server_domain_name_system.json +551 -0
- data/standards/stig_microsoft_windows_phone_8.1.json +161 -0
- data/standards/stig_microsoft_windows_server_2012_domain_controller.json +2633 -0
- data/standards/stig_microsoft_windows_server_2012_member_server.json +2411 -0
- data/standards/stig_microsoft_word_2003.json +47 -0
- data/standards/stig_microsoft_word_2007.json +119 -0
- data/standards/stig_microsoft_word_2010.json +221 -0
- data/standards/stig_microsoft_word_2013.json +221 -0
- data/standards/stig_microsoft_word_2016.json +215 -0
- data/standards/stig_mobile_application_management_mam_server.json +95 -0
- data/standards/stig_mobile_application_security_requirements_guide.json +233 -0
- data/standards/stig_mobile_device_integrity_scanning_mdis_server.json +119 -0
- data/standards/stig_mobile_device_management_mdm_server.json +125 -0
- data/standards/stig_mobile_device_manager_security_requirements_guide.json +2555 -0
- data/standards/stig_mobile_email_management_mem_server.json +197 -0
- data/standards/stig_mobile_operating_system_security_requirements_guide.json +1943 -0
- data/standards/stig_mobile_policy.json +35 -0
- data/standards/stig_mobile_policy_security_requirements_guide.json +437 -0
- data/standards/stig_mobileiron_core_v9.x_mdm.json +89 -0
- data/standards/stig_mobility_policy.json +65 -0
- data/standards/stig_mozilla_firefox.json +161 -0
- data/standards/stig_ms_exchange_2013_client_access_server.json +209 -0
- data/standards/stig_ms_exchange_2013_edge_transport_server.json +443 -0
- data/standards/stig_ms_exchange_2013_mailbox_server.json +437 -0
- data/standards/stig_ms_sharepoint_2010.json +269 -0
- data/standards/stig_ms_sharepoint_2013.json +245 -0
- data/standards/stig_ms_sharepoint_designer_2013.json +71 -0
- data/standards/stig_ms_sql_server_2014_database.json +263 -0
- data/standards/stig_ms_sql_server_2014_instance.json +575 -0
- data/standards/stig_ms_sql_server_2016_database.json +185 -0
- data/standards/stig_ms_sql_server_2016_instance.json +731 -0
- data/standards/stig_ms_windows_defender_antivirus.json +257 -0
- data/standards/stig_multifunction_device_and_network_printers.json +131 -0
- data/standards/stig_network_device_management_security_requirements_guide.json +863 -0
- data/standards/stig_network_devices.json +389 -0
- data/standards/stig_network_infrastructure_policy.json +455 -0
- data/standards/stig_network_security_requirements_guide.json +1961 -0
- data/standards/stig_operating_system_security_requirements_guide.json +1961 -0
- data/standards/stig_oracle_10_database_installation.json +527 -0
- data/standards/stig_oracle_10_database_instance.json +569 -0
- data/standards/stig_oracle_11_database_installation.json +527 -0
- data/standards/stig_oracle_11_database_instance.json +551 -0
- data/standards/stig_oracle_database_10g_installation.json +527 -0
- data/standards/stig_oracle_database_10g_instance.json +581 -0
- data/standards/stig_oracle_database_11.2g.json +1229 -0
- data/standards/stig_oracle_database_11g_installation.json +527 -0
- data/standards/stig_oracle_database_11g_instance.json +575 -0
- data/standards/stig_oracle_database_12c.json +1217 -0
- data/standards/stig_oracle_http_server_12.1.3.json +1703 -0
- data/standards/stig_oracle_linux_5.json +3431 -0
- data/standards/stig_oracle_linux_6.json +1583 -0
- data/standards/stig_oracle_weblogic_server_12c.json +443 -0
- data/standards/stig_palo_alto_networks_alg.json +311 -0
- data/standards/stig_palo_alto_networks_idps.json +185 -0
- data/standards/stig_palo_alto_networks_ndm.json +251 -0
- data/standards/stig_pda.json +83 -0
- data/standards/stig_pdasmartphone.json +95 -0
- data/standards/stig_perimeter_l3_switch.json +923 -0
- data/standards/stig_perimeter_l3_switch_-_cisco.json +1001 -0
- data/standards/stig_perimeter_router.json +803 -0
- data/standards/stig_perimeter_router_cisco.json +881 -0
- data/standards/stig_perimeter_router_juniper.json +803 -0
- data/standards/stig_postgresql_9.x.json +677 -0
- data/standards/stig_red_hat_enterprise_linux_5.json +3437 -0
- data/standards/stig_red_hat_enterprise_linux_6.json +1565 -0
- data/standards/stig_red_hat_enterprise_linux_7.json +1451 -0
- data/standards/stig_remote_access_policy.json +317 -0
- data/standards/stig_removable_storage_and_external_connection_technologies.json +143 -0
- data/standards/stig_removable_storage_and_external_connections.json +137 -0
- data/standards/stig_rfid_scanner.json +35 -0
- data/standards/stig_rfid_workstation.json +23 -0
- data/standards/stig_riverbed_steelhead_cx_v8_alg.json +83 -0
- data/standards/stig_riverbed_steelhead_cx_v8_ndm.json +371 -0
- data/standards/stig_router_security_requirements_guide.json +575 -0
- data/standards/stig_samsung_android_os_5_with_knox_2.0.json +365 -0
- data/standards/stig_samsung_android_os_6_with_knox_2.x.json +377 -0
- data/standards/stig_samsung_android_os_7_with_knox_2.x.json +443 -0
- data/standards/stig_samsung_android_with_knox_1.x.json +293 -0
- data/standards/stig_samsung_android_with_knox_2.x.json +371 -0
- data/standards/stig_samsung_knox_android_1.0.json +167 -0
- data/standards/stig_sharepoint_2010.json +269 -0
- data/standards/stig_sharepoint_2013.json +245 -0
- data/standards/stig_smartphone_policy.json +131 -0
- data/standards/stig_solaris_10_sparc.json +3029 -0
- data/standards/stig_solaris_10_x86.json +3065 -0
- data/standards/stig_solaris_11_sparc.json +1427 -0
- data/standards/stig_solaris_11_x86.json +1421 -0
- data/standards/stig_solaris_9_sparc.json +2915 -0
- data/standards/stig_solaris_9_x86.json +2915 -0
- data/standards/stig_sun_ray_4.json +185 -0
- data/standards/stig_sun_ray_4_policy.json +77 -0
- data/standards/stig_suse_linux_enterprise_server_v11system_z.json +3311 -0
- data/standards/stig_symantec_endpoint_protection_12.1_local_client_antivirus.json +689 -0
- data/standards/stig_symantec_endpoint_protection_12.1_managed_client_antivirus.json +695 -0
- data/standards/stig_tanium_6.5.json +461 -0
- data/standards/stig_tanium_7.0.json +803 -0
- data/standards/stig_test_and_development_zone_a.json +167 -0
- data/standards/stig_test_and_development_zone_b.json +179 -0
- data/standards/stig_test_and_development_zone_c.json +143 -0
- data/standards/stig_test_and_development_zone_d.json +143 -0
- data/standards/stig_traditional_security.json +917 -0
- data/standards/stig_unix_srg.json +3287 -0
- data/standards/stig_video_services_policy.json +497 -0
- data/standards/stig_video_teleconference.json +47 -0
- data/standards/stig_video_teleconference_vtc.json +12 -0
- data/standards/stig_vmware_esx_3_policy.json +155 -0
- data/standards/stig_vmware_esx_3_server.json +3791 -0
- data/standards/stig_vmware_esx_3_virtual_center.json +257 -0
- data/standards/stig_vmware_esx_3_virtual_machine.json +53 -0
- data/standards/stig_vmware_esxi_server_5.0.json +809 -0
- data/standards/stig_vmware_esxi_v5.json +5177 -0
- data/standards/stig_vmware_esxi_version_5_virtual_machine.json +317 -0
- data/standards/stig_vmware_nsx_distributed_firewall.json +83 -0
- data/standards/stig_vmware_nsx_distributed_logical_router.json +35 -0
- data/standards/stig_vmware_nsx_manager.json +191 -0
- data/standards/stig_vmware_vcenter_server.json +179 -0
- data/standards/stig_vmware_vcenter_server_version_5.json +149 -0
- data/standards/stig_vmware_vsphere_esxi_6.0.json +659 -0
- data/standards/stig_vmware_vsphere_vcenter_server_version_6.json +311 -0
- data/standards/stig_vmware_vsphere_virtual_machine_version_6.json +269 -0
- data/standards/stig_voice_and_video_over_internet_protocol_vvoip_policy.json +407 -0
- data/standards/stig_voice_video_endpoint_security_requirements_guide.json +395 -0
- data/standards/stig_voice_video_services_policy.json +671 -0
- data/standards/stig_voice_video_session_management_security_requirements_guide.json +329 -0
- data/standards/stig_voicevideo_over_internet_protocol.json +419 -0
- data/standards/stig_voicevideo_over_internet_protocol_vvoip.json +263 -0
- data/standards/stig_voicevideo_services_policy.json +569 -0
- data/standards/stig_web_policy.json +95 -0
- data/standards/stig_web_server.json +317 -0
- data/standards/stig_web_server_security_requirements_guide.json +587 -0
- data/standards/stig_win2k3_audit.json +761 -0
- data/standards/stig_win2k8_audit.json +1085 -0
- data/standards/stig_win2k8_r2_audit.json +1637 -0
- data/standards/stig_win7_audit.json +1613 -0
- data/standards/stig_windows_10.json +1691 -0
- data/standards/stig_windows_2003_domain_controller.json +893 -0
- data/standards/stig_windows_2003_member_server.json +845 -0
- data/standards/stig_windows_2008_domain_controller.json +1475 -0
- data/standards/stig_windows_2008_member_server.json +1301 -0
- data/standards/stig_windows_7.json +1781 -0
- data/standards/stig_windows_8.json +2399 -0
- data/standards/stig_windows_88.1.json +2273 -0
- data/standards/stig_windows_8_8.1.json +2297 -0
- data/standards/stig_windows_defender_antivirus.json +239 -0
- data/standards/stig_windows_dns.json +185 -0
- data/standards/stig_windows_firewall_with_advanced_security.json +137 -0
- data/standards/stig_windows_paw.json +155 -0
- data/standards/stig_windows_phone_6.5_with_good_mobility_suite.json +65 -0
- data/standards/stig_windows_server_2008_r2_domain_controller.json +1961 -0
- data/standards/stig_windows_server_2008_r2_member_server.json +1745 -0
- data/standards/stig_windows_server_20122012_r2_domain_controller.json +2255 -0
- data/standards/stig_windows_server_20122012_r2_member_server.json +2045 -0
- data/standards/stig_windows_server_2012_2012_r2_domain_controller.json +2279 -0
- data/standards/stig_windows_server_2012_2012_r2_member_server.json +2075 -0
- data/standards/stig_windows_server_2012_domain_controller.json +2471 -0
- data/standards/stig_windows_server_2012_member_server.json +2249 -0
- data/standards/stig_windows_server_2016.json +1661 -0
- data/standards/stig_windows_vista.json +1517 -0
- data/standards/stig_windows_xp.json +893 -0
- data/standards/stig_wireless_keyboard_and_mouse.json +23 -0
- data/standards/stig_wireless_management_server_policy.json +53 -0
- data/standards/stig_wireless_remote_access_policy_security_implementation_guide.json +29 -0
- data/standards/stig_wlan_access_point_enclave-niprnet_connected.json +227 -0
- data/standards/stig_wlan_access_point_internet_gateway_only_connection.json +209 -0
- data/standards/stig_wlan_access_point_policy.json +17 -0
- data/standards/stig_wlan_authentication_server.json +29 -0
- data/standards/stig_wlan_bridge.json +209 -0
- data/standards/stig_wlan_client.json +65 -0
- data/standards/stig_wlan_controller.json +215 -0
- data/standards/stig_wlan_ids_sensorserver.json +23 -0
- data/standards/stig_wman_access_point.json +263 -0
- data/standards/stig_wman_bridge.json +209 -0
- data/standards/stig_wman_subscriber.json +65 -0
- data/standards/stig_zos_acf2.json +1451 -0
- data/standards/stig_zos_bmc_control-dacf2.json +53 -0
- data/standards/stig_zos_bmc_control-dracf.json +59 -0
- data/standards/stig_zos_bmc_control-dtss.json +65 -0
- data/standards/stig_zos_bmc_control-macf2.json +59 -0
- data/standards/stig_zos_bmc_control-mracf.json +65 -0
- data/standards/stig_zos_bmc_control-mrestartacf2.json +23 -0
- data/standards/stig_zos_bmc_control-mrestartracf.json +23 -0
- data/standards/stig_zos_bmc_control-mrestarttss.json +23 -0
- data/standards/stig_zos_bmc_control-mtss.json +71 -0
- data/standards/stig_zos_bmc_control-oacf2.json +53 -0
- data/standards/stig_zos_bmc_control-oracf.json +59 -0
- data/standards/stig_zos_bmc_control-otss.json +65 -0
- data/standards/stig_zos_bmc_ioaacf2.json +53 -0
- data/standards/stig_zos_bmc_ioaracf.json +59 -0
- data/standards/stig_zos_bmc_ioatss.json +65 -0
- data/standards/stig_zos_bmc_mainviewzosacf2.json +47 -0
- data/standards/stig_zos_bmc_mainviewzosracf.json +53 -0
- data/standards/stig_zos_bmc_mainviewzostss.json +59 -0
- data/standards/stig_zos_ca_1_tape_managementacf2.json +65 -0
- data/standards/stig_zos_ca_1_tape_managementracf.json +77 -0
- data/standards/stig_zos_ca_1_tape_managementtss.json +77 -0
- data/standards/stig_zos_ca_auditoracf2.json +29 -0
- data/standards/stig_zos_ca_auditorracf.json +29 -0
- data/standards/stig_zos_ca_auditortss.json +29 -0
- data/standards/stig_zos_ca_common_servicesacf2.json +23 -0
- data/standards/stig_zos_ca_common_servicesracf.json +29 -0
- data/standards/stig_zos_ca_common_servicestss.json +29 -0
- data/standards/stig_zos_ca_micsacf2.json +23 -0
- data/standards/stig_zos_ca_micsracf.json +23 -0
- data/standards/stig_zos_ca_micstss.json +23 -0
- data/standards/stig_zos_ca_mimacf2.json +41 -0
- data/standards/stig_zos_ca_mimracf.json +47 -0
- data/standards/stig_zos_ca_mimtss.json +47 -0
- data/standards/stig_zos_ca_vtapeacf2.json +29 -0
- data/standards/stig_zos_ca_vtaperacf.json +35 -0
- data/standards/stig_zos_ca_vtapetss.json +35 -0
- data/standards/stig_zos_catalog_solutionsacf2.json +23 -0
- data/standards/stig_zos_catalog_solutionsracf.json +23 -0
- data/standards/stig_zos_catalog_solutionstss.json +23 -0
- data/standards/stig_zos_clsupersessionacf2.json +53 -0
- data/standards/stig_zos_clsupersessionracf.json +65 -0
- data/standards/stig_zos_clsupersessiontss.json +71 -0
- data/standards/stig_zos_compuware_abend-aidacf2.json +47 -0
- data/standards/stig_zos_compuware_abend-aidracf.json +53 -0
- data/standards/stig_zos_compuware_abend-aidtss.json +53 -0
- data/standards/stig_zos_cssmtpacf2.json +23 -0
- data/standards/stig_zos_cssmtpracf.json +29 -0
- data/standards/stig_zos_cssmtptss.json +29 -0
- data/standards/stig_zos_fdracf2.json +23 -0
- data/standards/stig_zos_fdrracf.json +23 -0
- data/standards/stig_zos_fdrtss.json +23 -0
- data/standards/stig_zos_hcdacf2.json +29 -0
- data/standards/stig_zos_hcdracf.json +29 -0
- data/standards/stig_zos_hcdtss.json +29 -0
- data/standards/stig_zos_ibm_cics_transaction_serveracf2.json +17 -0
- data/standards/stig_zos_ibm_cics_transaction_serverracf.json +17 -0
- data/standards/stig_zos_ibm_cics_transaction_servertss.json +17 -0
- data/standards/stig_zos_ibm_health_checkeracf2.json +23 -0
- data/standards/stig_zos_ibm_health_checkerracf.json +29 -0
- data/standards/stig_zos_ibm_health_checkertss.json +29 -0
- data/standards/stig_zos_ibm_system_display_and_search_facility_sdsfacf2.json +53 -0
- data/standards/stig_zos_ibm_system_display_and_search_facility_sdsfracf.json +59 -0
- data/standards/stig_zos_ibm_system_display_and_search_facility_sdsftss.json +53 -0
- data/standards/stig_zos_icsfacf2.json +29 -0
- data/standards/stig_zos_icsfracf.json +35 -0
- data/standards/stig_zos_icsftss.json +35 -0
- data/standards/stig_zos_netviewacf2.json +41 -0
- data/standards/stig_zos_netviewracf.json +47 -0
- data/standards/stig_zos_netviewtss.json +53 -0
- data/standards/stig_zos_quest_nc-passacf2.json +35 -0
- data/standards/stig_zos_quest_nc-passracf.json +41 -0
- data/standards/stig_zos_quest_nc-passtss.json +47 -0
- data/standards/stig_zos_racf.json +1415 -0
- data/standards/stig_zos_roscoeacf2.json +47 -0
- data/standards/stig_zos_roscoeracf.json +53 -0
- data/standards/stig_zos_roscoetss.json +59 -0
- data/standards/stig_zos_srrauditacf2.json +23 -0
- data/standards/stig_zos_srrauditracf.json +23 -0
- data/standards/stig_zos_srraudittss.json +23 -0
- data/standards/stig_zos_tadzacf2.json +29 -0
- data/standards/stig_zos_tadzracf.json +35 -0
- data/standards/stig_zos_tadztss.json +35 -0
- data/standards/stig_zos_tdmfacf2.json +23 -0
- data/standards/stig_zos_tdmfracf.json +23 -0
- data/standards/stig_zos_tdmftss.json +23 -0
- data/standards/stig_zos_tss.json +1523 -0
- data/standards/stig_zos_vssracf.json +29 -0
- metadata +691 -0
|
@@ -0,0 +1,431 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "stig_bind_9.x",
|
|
3
|
+
"date": "2018-04-03",
|
|
4
|
+
"description": "This 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.",
|
|
5
|
+
"title": "BIND 9.x Security Technical Implementation Guide",
|
|
6
|
+
"version": "1",
|
|
7
|
+
"item_syntax": "^\\w-\\d+$",
|
|
8
|
+
"section_separator": null,
|
|
9
|
+
"items": [
|
|
10
|
+
{
|
|
11
|
+
"id": "V-72363",
|
|
12
|
+
"title": "A BIND 9.x server implementation must be running in a chroot(ed) directory structure.",
|
|
13
|
+
"description": "With any network service, there is the potential that an attacker can exploit a vulnerability within the program that allows the attacker to gain control of the process and even run system commands with that control. One possible defense against this attack is to limit the software to particular quarantined areas of the file system, memory or both. This effectively restricts the service so that it will not have access to the full file system. If such a defense were in place, then even if an attacker gained control of the process, the attacker would be unable to reach other commands or files on the system. This approach often is referred to as a padded cell, jail, or sandbox. All of these terms allude to the fact that the software is contained in an area where it cannot harm either itself or others. A more technical term is a chroot(ed) directory structure.\n\nBIND should be configured to run in a padded cell or chroot(ed) directory structure.",
|
|
14
|
+
"severity": "low"
|
|
15
|
+
},
|
|
16
|
+
{
|
|
17
|
+
"id": "V-72365",
|
|
18
|
+
"title": "A BIND 9.x server implementation must be operating on a Current-Stable version as defined by ISC.",
|
|
19
|
+
"description": "The BIND STIG was written to incorporate capabilities and features provided in BIND version 9.9.x. However, it is recognized that security vulnerabilities in BIND are identified and then addressed on a regular, ongoing basis. Therefore it is required that the product be maintained at the latest stable versions in order to address vulnerabilities that are subsequently identified and can then be remediated via updates to the product.\n\nFailure to run a version of BIND that has the capability to implement all of the required security features and that does provide services compliant to the DNS RFCs can have a severe impact on the security posture of a DNS infrastructure. Without the required security in place, a DNS implementation is vulnerable to many types of attacks and could be used as a launching point for further attacks on the organizational network that is utilizing the DNS implementation.\n\nSatisfies: SRG-APP-000516-DNS-000097, SRG-APP-000516-DNS-000103",
|
|
20
|
+
"severity": "high"
|
|
21
|
+
},
|
|
22
|
+
{
|
|
23
|
+
"id": "V-72367",
|
|
24
|
+
"title": "The platform on which the name server software is hosted must only run processes and services needed to support the BIND 9.x implementation.",
|
|
25
|
+
"description": "Hosts that run the name server software should not provide any other services. Unnecessary services running on the DNS server can introduce additional attack vectors leading to the compromise of an organization’s DNS architecture.",
|
|
26
|
+
"severity": "medium"
|
|
27
|
+
},
|
|
28
|
+
{
|
|
29
|
+
"id": "V-72369",
|
|
30
|
+
"title": "The BIND 9.x server software must run with restricted privileges.",
|
|
31
|
+
"description": "Failure to provide logical access restrictions associated with changes to application configuration may have significant effects on the overall security of the system. When dealing with access restrictions pertaining to change control, it should be noted that any changes to the hardware, software, and/or firmware components of the information system and/or application can have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals should be allowed to obtain access to application components for the purposes of initiating changes, including upgrades and modifications.",
|
|
32
|
+
"severity": "medium"
|
|
33
|
+
},
|
|
34
|
+
{
|
|
35
|
+
"id": "V-72371",
|
|
36
|
+
"title": "The host running a BIND 9.X implementation must implement a set of firewall rules that restrict traffic on the DNS interface.",
|
|
37
|
+
"description": "Configuring hosts that run a BIND 9.X implementation to only accept DNS traffic on a DNS interface allows a system firewall to be configured to limit the allowed incoming ports/protocols to 53/tcp and 53/udp. Sending outgoing DNS messages from a random port minimizes the risk of an attacker guessing the outgoing message port and sending forged replies.\n\nThe TCP/IP stack in DNS hosts (stub resolver, caching/resolving/recursive name server, authoritative name server, etc.) could be subjected to packet flooding attacks (such as SYNC and smurf), resulting in disruption of communication. By implementing a specific set of firewall rules that limit accepted traffic to the interface, these risk of packet flooding and other TCP/IP based attacks is reduced.",
|
|
38
|
+
"severity": "medium"
|
|
39
|
+
},
|
|
40
|
+
{
|
|
41
|
+
"id": "V-72373",
|
|
42
|
+
"title": "The host running a BIND 9.x implementation must use a dedicated management interface in order to separate management traffic from DNS specific traffic.",
|
|
43
|
+
"description": "Providing Out-Of-Band (OOB) management is the best first step in any management strategy. No production traffic resides on an out-of-band network. The biggest advantage to implementation of an OOB network is providing support and maintenance to the network that has become degraded or compromised. During an outage or degradation period the in band management link may not be available.",
|
|
44
|
+
"severity": "medium"
|
|
45
|
+
},
|
|
46
|
+
{
|
|
47
|
+
"id": "V-72375",
|
|
48
|
+
"title": "The host running a BIND 9.x implementation must use an interface that is configured to process only DNS traffic.",
|
|
49
|
+
"description": "Configuring hosts that run a BIND 9.X implementation to only accept DNS traffic on a DNS interface allows a system to be configured to segregate DNS traffic from all other host traffic.\n\nThe TCP/IP stack in DNS hosts (stub resolver, caching/resolving/recursive name server, authoritative name server, etc.) could be subjected to packet flooding attacks (such as SYNC and smurf), resulting in disruption of communication. \n\nThe use of a dedicated interface for DNS traffic allows for these threats to be mitigated by creating a means to limit what types of traffic can be processed using a host based firewall solution.",
|
|
50
|
+
"severity": "medium"
|
|
51
|
+
},
|
|
52
|
+
{
|
|
53
|
+
"id": "V-72377",
|
|
54
|
+
"title": "A BIND 9.x server implementation must be configured to allow DNS administrators to audit all DNS server components, based on selectable event criteria, and produce audit records within all DNS server components that contain information for failed security verification tests, information to establish the outcome and source of the events, any information necessary to determine cause of failure, and any information necessary to return to operations with least disruption to mission processes.",
|
|
55
|
+
"description": "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.\n\nThe list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. \n\nThe DoD has defined the list of events for which the application will provide an audit record generation capability as the following: \n\n(i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n\n(ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and\n\n(iii) All account creation, modification, disabling, and termination actions.\n\nThe DoD has defined the data which the application will provide an audit record generation capability for an event as the following: \n\n(i) Establish the source of the event;\n\n(ii) The outcome of the event; and\n\n(iii) Identify the application itself as the source of the event.\n\nWithout establishing the source of the event, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. Associating information about the source of the event within the application provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured application. \n\nWithout information about the outcome of events, security personnel cannot make an accurate assessment about whether an attack was successful or if changes were made to the security state of the system.\n\nEvent outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the information system after the event occurred). As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response.\"\nFailure to a known state can address safety or security in accordance with the mission/business needs of the organization. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving application state information helps to facilitate application restart and return to the operational mode of the organization with less disruption to mission-essential processes.\n\nThe DNS server should be configured to generate audit records whenever a self-test fails. The OS/NDM is responsible for generating notification messages related to this audit record.\n\nIf authorized individuals do not have the ability to modify auditing parameters in response to a changing threat environment, the organization may not be able to effectively respond, and important forensic information may be lost.\n\nThis requirement enables organizations to extend or limit auditing as necessary to meet organizational requirements. Auditing that is limited to conserve information system resources may be extended to address certain threat situations. In addition, auditing may be limited to a specific set of events to facilitate audit reduction, analysis, and reporting. Organizations can establish time thresholds in which audit actions are changed, for example, near real-time, within minutes, or within hours.\n\nIn addition to logging where events occur within the application, the application must also produce audit records that identify the application itself as the source of the event. In order to compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know the source of the event, particularly in the case of centralized logging. In the case of centralized logging, the source would be the application name accompanied by the host or client name.\n\nSatisfies: SRG-APP-000089-DNS-000004, SRG-APP-000098-DNS-000009, SRG-APP-000099-DNS-000010, SRG-APP-000226-DNS-000032, SRG-APP-000275-DNS-000040, SRG-APP-000353-DNS-000045",
|
|
56
|
+
"severity": "low"
|
|
57
|
+
},
|
|
58
|
+
{
|
|
59
|
+
"id": "V-72379",
|
|
60
|
+
"title": "The BIND 9.x server implementation must not be configured with a channel to send audit records to null.",
|
|
61
|
+
"description": "DNS software administrators require DNS transaction logs for a wide variety of reasons including troubleshooting, intrusion detection, and forensics. Ensuring that the DNS transaction logs are recorded on the local system will provide the capability needed to support these actions. Sending DNS transaction data to the null channel would cause a loss of important data.",
|
|
62
|
+
"severity": "low"
|
|
63
|
+
},
|
|
64
|
+
{
|
|
65
|
+
"id": "V-72381",
|
|
66
|
+
"title": "The BIND 9.x server logging configuration must be configured to generate audit records for all DoD-defined auditable events to a local file by enabling triggers for all events with a severity of info, notice, warning, error, and critical for all DNS components.",
|
|
67
|
+
"description": "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.\n\nThe list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. \n\nThe DoD has defined the list of events for which the application will provide an audit record generation capability as the following: \n\n(i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n\n(ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and\n\n(iii) All account creation, modification, disabling, and termination actions.",
|
|
68
|
+
"severity": "low"
|
|
69
|
+
},
|
|
70
|
+
{
|
|
71
|
+
"id": "V-72383",
|
|
72
|
+
"title": "In the event of an error when validating the binding of other DNS servers identity to the BIND 9.x information, when anomalies in the operation of the signed zone transfers are discovered, for the success and failure of start and stop of the name server service or daemon, and for the success and failure of all name server events, a BIND 9.x server implementation must generate a log entry.",
|
|
73
|
+
"description": "Auditing and logging are key components of any security architecture. It is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered, in order to compile an accurate risk assessment. Logging the actions of specific events provides a means to investigate an attack, to recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis.\n\nThe DNS server should audit all failed attempts at server authentication through DNSSEC and TSIG. The actual auditing is performed by the OS/NDM but the configuration to trigger the auditing is controlled by the DNS server.\n\nFailing to act on the validation errors may result in the use of invalid, corrupted, or compromised information. The validation of bindings can be achieved, for example, by the use of cryptographic checksums. Validations must be performed automatically.\n\nThe 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.\n\nSatisfies: SRG-APP-000350-DNS-000044, SRG-APP-000474-DNS-000073, SRG-APP-000504-DNS-000074, SRG-APP-000504-DNS-000082",
|
|
74
|
+
"severity": "low"
|
|
75
|
+
},
|
|
76
|
+
{
|
|
77
|
+
"id": "V-72385",
|
|
78
|
+
"title": "The print-severity variable for the configuration of BIND 9.x server logs must be configured to produce audit records containing information to establish what type of events occurred.",
|
|
79
|
+
"description": "Auditing and logging are key components of any security architecture. It is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered, in order to compile an accurate risk assessment. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS implementation. Without log records that aid in the establishment of what types of events occurred and when those events occurred, there is no traceability for forensic or analytical purposes, and the cause of events is severely hindered.",
|
|
80
|
+
"severity": "low"
|
|
81
|
+
},
|
|
82
|
+
{
|
|
83
|
+
"id": "V-72387",
|
|
84
|
+
"title": "The print-time variable for the configuration of BIND 9.x server logs must be configured to establish when (date and time) the events occurred.",
|
|
85
|
+
"description": "Without establishing when events occurred, it is impossible to establish, correlate, and investigate the events relating to an incident. \n\nAssociating event types with detected events in the application and audit logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured application. In order to compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know when events occurred (date and time).",
|
|
86
|
+
"severity": "low"
|
|
87
|
+
},
|
|
88
|
+
{
|
|
89
|
+
"id": "V-72389",
|
|
90
|
+
"title": "The print-category variable for the configuration of BIND 9.x server logs must be configured to record information indicating which process generated the events.",
|
|
91
|
+
"description": "Without establishing where events occurred, it is impossible to establish, correlate, and investigate the events relating to an incident. Associating information about where the event occurred within the application provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured application. In order to compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know where events occurred, such as application components, modules, session identifiers, filenames, host names, and functionality.",
|
|
92
|
+
"severity": "low"
|
|
93
|
+
},
|
|
94
|
+
{
|
|
95
|
+
"id": "V-72391",
|
|
96
|
+
"title": "The BIND 9.x server implementation must be configured with a channel to send audit records to a remote syslog.",
|
|
97
|
+
"description": "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. \n\nThis helps to ensure a compromise of the information system being audited does not also result in a compromise of the audit records.",
|
|
98
|
+
"severity": "low"
|
|
99
|
+
},
|
|
100
|
+
{
|
|
101
|
+
"id": "V-72393",
|
|
102
|
+
"title": "The BIND 9.x server implementation must be configured with a channel to send audit records to a local file.",
|
|
103
|
+
"description": "DNS software administrators require DNS transaction logs for a wide variety of reasons including troubleshooting, intrusion detection, and forensics. Ensuring that the DNS transaction logs are recorded on the local system will provide the capability needed to support these actions.",
|
|
104
|
+
"severity": "low"
|
|
105
|
+
},
|
|
106
|
+
{
|
|
107
|
+
"id": "V-72395",
|
|
108
|
+
"title": "The BIND 9.x server implementation must maintain at least 3 file versions of the local log file.",
|
|
109
|
+
"description": "DNS software administrators require DNS transaction logs for a wide variety of reasons including troubleshooting, intrusion detection, and forensics. Ensuring that the DNS transaction logs are recorded on the local system will provide the capability needed to support these actions.",
|
|
110
|
+
"severity": "low"
|
|
111
|
+
},
|
|
112
|
+
{
|
|
113
|
+
"id": "V-72397",
|
|
114
|
+
"title": "The BIND 9.x secondary name server must limit the number of zones requested from a single master name server.",
|
|
115
|
+
"description": "Limiting the number of concurrent sessions reduces the risk of Denial of Service (DoS) to the DNS implementation.\n\nName servers do not have direct user connections but accept client connections for queries. Original restriction on client connections should be high enough to prevent a self-imposed denial of service, after which the connections are monitored and fine-tuned to best meet the organization's specific requirements.",
|
|
116
|
+
"severity": "medium"
|
|
117
|
+
},
|
|
118
|
+
{
|
|
119
|
+
"id": "V-72399",
|
|
120
|
+
"title": "The BIND 9.x secondary name server must limit the total number of zones the name server can request at any one time.",
|
|
121
|
+
"description": "Limiting the number of concurrent sessions reduces the risk of Denial of Service (DoS) to the DNS implementation.\n\nName servers do not have direct user connections but accept client connections for queries. Original restriction on client connections should be high enough to prevent a self-imposed denial of service, after which the connections are monitored and fine-tuned to best meet the organization's specific requirements.",
|
|
122
|
+
"severity": "medium"
|
|
123
|
+
},
|
|
124
|
+
{
|
|
125
|
+
"id": "V-72401",
|
|
126
|
+
"title": "The BIND 9.x server implementation must limit the number of concurrent session client connections to the number of allowed dynamic update clients.",
|
|
127
|
+
"description": "Limiting the number of concurrent sessions reduces the risk of Denial of Service (DoS) to the DNS implementation. \n\nName servers do not have direct user connections but accept client connections for queries. Original restriction on client connections should be high enough to prevent a self-imposed denial of service, after which the connections are monitored and fine-tuned to best meet the organization's specific requirements.",
|
|
128
|
+
"severity": "medium"
|
|
129
|
+
},
|
|
130
|
+
{
|
|
131
|
+
"id": "V-72403",
|
|
132
|
+
"title": "The BIND 9.x server implementation must be configured to use only approved ports and protocols.",
|
|
133
|
+
"description": "In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems.\n\nApplications are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations.\n\nTo support the requirements and principles of least functionality, the application must support the organizational requirements by providing only essential capabilities and limiting the use of ports, protocols, and/or services.",
|
|
134
|
+
"severity": "medium"
|
|
135
|
+
},
|
|
136
|
+
{
|
|
137
|
+
"id": "V-72405",
|
|
138
|
+
"title": "A BIND 9.x server implementation must manage excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of Denial of Service (DoS) attacks.",
|
|
139
|
+
"description": "A DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. \n\nA denial of service (DoS) attack against the DNS infrastructure has the potential to cause a DoS to all network users. As the DNS is a distributed backbone service of the Internet, various forms of amplification attacks resulting in DoS, while utilizing the DNS, are still prevalent on the Internet today. Some potential DoS flooding attacks against the DNS include malformed packet flood, spoofed source addresses, and distributed DoS. Without the DNS, users and systems would not have the ability to perform simple name to IP resolution. \n\nConfiguring the DNS implementation to defend against cache poisoning, employing increased capacity and bandwidth, building redundancy into the DNS architecture, utilizing DNSSEC, limiting and securing recursive services, DNS black holes, etc., may reduce the susceptibility to some flooding types of DoS attacks.",
|
|
140
|
+
"severity": "medium"
|
|
141
|
+
},
|
|
142
|
+
{
|
|
143
|
+
"id": "V-72407",
|
|
144
|
+
"title": "A BIND 9.x server implementation must prohibit recursion on authoritative name servers.",
|
|
145
|
+
"description": "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. \n\nTo 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.\n\nDNSSEC ensures that the answer received when querying for name resolution actually comes from a trusted name server. Since DNSSEC is still far from being globally deployed external to DoD, and many resolvers either have not been updated or do not support DNSSEC, maintaining cached zone data separate from authoritative zone data mitigates the gap until all DNS data is validated with DNSSEC. \n\nSince DNS forwarding of queries can be accomplished in some DNS applications without caching locally, DNS forwarding is the method to be used when providing external DNS resolution to internal clients.\n\nSatisfies: SRG-APP-000246-DNS-000035, SRG-APP-000383-DNS-000047",
|
|
146
|
+
"severity": "medium"
|
|
147
|
+
},
|
|
148
|
+
{
|
|
149
|
+
"id": "V-72409",
|
|
150
|
+
"title": "The master servers in a BIND 9.x implementation must notify authorized secondary name servers when zone files are updated.",
|
|
151
|
+
"description": "It is important to maintain the integrity of a zone file. The serial number of the SOA record is used to indicate to secondary name server that a change to the zone has occurred and a zone transfer should be performed. The serial number used in the SOA record provides the DNS administrator a method to verify the integrity of the zone file based on the serial number of the last update and ensure that all slave servers are using the correct zone file.\nWhen a primary master name server notices that the serial number of a zone has changed, it sends a special announcement to all of the slave name servers for that zone. The primary master name server determines which servers are the slaves for the zone by looking at the list of NS records in the zone and taking out the record that points to the name server listed in the MNAME field of the zone's SOA record as well as the domain name of the local host.\nWhen a secondary name server receives a NOTIFY announcement for a zone from one of its configured master name servers, it responds with a NOTIFY response. The response tells the master that the slave received the NOTIFY announcement so that the master can stop sending it NOTIFY announcements for the zone. Then the slave proceeds just as if the refresh timer for that zone had expired: it queries the master name server for the SOA record for the zone that the master claims has changed. If the serial number is higher, the slave transfers the zone.\nThe slave should next issue its own NOTIFY announcements to the other authoritative name servers for the zone. The idea is that the primary master may not be able to notify all of the slave name servers for the zone itself, since it's possible some slaves can't communicate directly with the primary master (they use another slave as their master). Older BIND 8 slaves don't send NOTIFY messages unless explicitly configured to do so.\n",
|
|
152
|
+
"severity": "low"
|
|
153
|
+
},
|
|
154
|
+
{
|
|
155
|
+
"id": "V-72411",
|
|
156
|
+
"title": "The secondary name servers in a BIND 9.x implementation must be configured to initiate zone update notifications to other authoritative zone name servers.",
|
|
157
|
+
"description": "It is important to maintain the integrity of a zone file. The serial number of the SOA record is used to indicate to secondary name server that a change to the zone has occurred and a zone transfer should be performed. The serial number used in the SOA record provides the DNS administrator a method to verify the integrity of the zone file based on the serial number of the last update and ensure that all slave servers are using the correct zone file.\nWhen a primary master name server notices that the serial number of a zone has changed, it sends a special announcement to all of the slave name servers for that zone. The primary master name server determines which servers are the slaves for the zone by looking at the list of NS records in the zone and taking out the record that points to the name server listed in the MNAME field of the zone's SOA record as well as the domain name of the local host.\nWhen a secondary name server receives a NOTIFY announcement for a zone from one of its configured master name servers, it responds with a NOTIFY response. The response tells the master that the slave received the NOTIFY announcement so that the master can stop sending it NOTIFY announcements for the zone. Then the slave proceeds just as if the refresh timer for that zone had expired: it queries the master name server for the SOA record for the zone that the master claims has changed. If the serial number is higher, the slave transfers the zone.\nThe slave should next issue its own NOTIFY announcements to the other authoritative name servers for the zone. The idea is that the primary master may not be able to notify all of the slave name servers for the zone itself, since it's possible some slaves can't communicate directly with the primary master (they use another slave as their master). Older BIND 8 slaves don't send NOTIFY messages unless explicitly configured to do so.\n",
|
|
158
|
+
"severity": "low"
|
|
159
|
+
},
|
|
160
|
+
{
|
|
161
|
+
"id": "V-72419",
|
|
162
|
+
"title": "On the BIND 9.x server the platform on which the name server software is hosted must be configured to send outgoing DNS messages from a random port.",
|
|
163
|
+
"description": "Hosts that run the name server software should not provide any other services and therefore should be configured to respond to DNS traffic only. Outgoing DNS messages should be sent from a random port to minimize the risk of an attacker's guessing the outgoing message port and sending forged replies.",
|
|
164
|
+
"severity": "low"
|
|
165
|
+
},
|
|
166
|
+
{
|
|
167
|
+
"id": "V-72421",
|
|
168
|
+
"title": "A BIND 9.x caching name server must implement DNSSEC validation to check all DNS queries for invalid input.",
|
|
169
|
+
"description": "A common vulnerability of applications is unpredictable behavior when invalid inputs are received. This requirement guards against adverse or unintended system behavior caused by invalid inputs, where information system responses to the invalid input may be disruptive or cause the system to fail into an unsafe state. \n\nAttacks may be generated by entering invalid data into DNS transactions, in the hopes that the data will not be handled correctly and will allow a vulnerable condition to be exploited. To safeguard against this, all untrusted data entered in DNS transactions (e.g., DNS queries) should be checked for validity before being processed further.",
|
|
170
|
+
"severity": "medium"
|
|
171
|
+
},
|
|
172
|
+
{
|
|
173
|
+
"id": "V-72423",
|
|
174
|
+
"title": "A BIND 9.x master name server must limit the number of concurrent zone transfers between authorized secondary name servers.",
|
|
175
|
+
"description": "Limiting the number of concurrent sessions reduces the risk of Denial of Service (DoS) to the DNS implementation.\n\nName servers do not have direct user connections but accept client connections for queries. Original restriction on client connections should be high enough to prevent a self-imposed denial of service, after which the connections are monitored and fine-tuned to best meet the organization's specific requirements.\n\nPrimary name servers also make outbound connection to secondary name servers to provide zone transfers and accept inbound connection requests from clients wishing to provide a dynamic update. Primary name servers should explicitly limit zone transfers to only be made to designated secondary name servers. Because zone transfers involve the transfer of entire zones and use TCP connections, they place substantial demands on network resources relative to normal DNS queries. Errant or malicious frequent zone transfer requests on the name servers of the enterprise can overload the master zone server and result in DoS to legitimate users. Primary name servers should be configured to limit the hosts from which they will accept dynamic updates.\n\nAdditionally, the number of concurrent clients, especially TCP clients, needs to be kept to a level that does not risk placing the system in a DoS state.",
|
|
176
|
+
"severity": "medium"
|
|
177
|
+
},
|
|
178
|
+
{
|
|
179
|
+
"id": "V-72425",
|
|
180
|
+
"title": "A BIND 9.x implementation configured as a caching name server must restrict recursive queries to only the IP addresses and IP address ranges of known supported clients.",
|
|
181
|
+
"description": "Any host that can query a resolving name server has the potential to poison the servers name cache or take advantage of other vulnerabilities that may be accessed through the query service. The best way to prevent this type of attack is to limit queries to internal hosts, which need to have this service available to them.\n\nTo 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.",
|
|
182
|
+
"severity": "medium"
|
|
183
|
+
},
|
|
184
|
+
{
|
|
185
|
+
"id": "V-72429",
|
|
186
|
+
"title": "The BIND 9.x server implementation must uniquely identify and authenticate the other DNS server before responding to a server-to-server transaction, zone transfer and/or dynamic update request using cryptographically based bidirectional authentication to protect the integrity of the information in transit.",
|
|
187
|
+
"description": "Server-to-server (zone transfer) transactions are provided by TSIG, which enforces mutual server authentication using a key that is unique to each server pair (TSIG), thus uniquely identifying the other server. DNS does perform server authentication when TSIG is used, but this authentication is transactional in nature (each transaction has its own authentication performed).\n\nEnforcing mutually authenticated communication sessions during zone transfers provides the assurance that only authorized servers are requesting and receiving DNS zone data. Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity.\n\nFailure to properly implement transactional security may have significant effects on the overall security of the DNS infrastructure. The lack of mutual authentication between name servers during a DNS transaction would allow a threat actor to launch a Man-In-The-Middle attack against the DNS infrastructure. This attack could lead to unauthorized DNS zone data being introduced, resulting in network traffic being redirected to a rogue site.\n\nSatisfies: SRG-APP-000158-DNS-000015, SRG-APP-000390-DNS-000048, SRG-APP-000394-DNS-000049, SRG-APP-000395-DNS-000050, SRG-APP-000439-DNS-000063, SRG-APP-000440-DNS-000065",
|
|
188
|
+
"severity": "high"
|
|
189
|
+
},
|
|
190
|
+
{
|
|
191
|
+
"id": "V-72431",
|
|
192
|
+
"title": "The BIND 9.x server implementation must utilize separate TSIG key-pairs when securing server-to-server transactions.",
|
|
193
|
+
"description": "Server-to-server (zone transfer) transactions are provided by TSIG, which enforces mutual server authentication using a key that is unique to each server pair (TSIG), thus uniquely identifying the other server.\n\nEnforcing separate TSIG key-pairs provides another layer of protection for the BIND implementation in the event that a TSIG key is compromised. This additional layer of security provides the DNS administrators with the ability to change a compromised TSIG key with a minimal disruption to DNS operations.\n\nFailure to identify devices and authenticate devices can lead to malicious activity, such as a Man-In-The-Middle attack where an attacker could pose as an authorized name server, and redirect legitimate customers to malicious websites. A failure on this part could also lead to a Denial of Service of any and all DNS services provided to an organizations network infrastructure.",
|
|
194
|
+
"severity": "medium"
|
|
195
|
+
},
|
|
196
|
+
{
|
|
197
|
+
"id": "V-72437",
|
|
198
|
+
"title": "The TSIG keys used with the BIND 9.x implementation must be owned by a privileged account.",
|
|
199
|
+
"description": "Incorrect ownership of a TSIG key file could allow an adversary to modify the file, thus defeating the security objective.",
|
|
200
|
+
"severity": "medium"
|
|
201
|
+
},
|
|
202
|
+
{
|
|
203
|
+
"id": "V-72439",
|
|
204
|
+
"title": "The TSIG keys used with the BIND 9.x implementation must be group owned by a privileged account.",
|
|
205
|
+
"description": "Incorrect ownership of a TSIG key file could allow an adversary to modify the file, thus defeating the security objective.",
|
|
206
|
+
"severity": "medium"
|
|
207
|
+
},
|
|
208
|
+
{
|
|
209
|
+
"id": "V-72441",
|
|
210
|
+
"title": "The read and write access to a TSIG key file used by a BIND 9.x server must be restricted to only the account that runs the name server software.",
|
|
211
|
+
"description": "Weak permissions of a TSIG key file could allow an adversary to modify the file, thus defeating the security objective.",
|
|
212
|
+
"severity": "medium"
|
|
213
|
+
},
|
|
214
|
+
{
|
|
215
|
+
"id": "V-72443",
|
|
216
|
+
"title": "The BIND 9.X implementation must not utilize a TSIG or DNSSEC key for more than one year.",
|
|
217
|
+
"description": "Cryptographic keys are the backbone of securing DNS information over the wire, maintaining DNS data integrity, and the providing the ability to validate DNS information that is received.\n\nWhen a cryptographic key is utilized by a DNS server for a long period of time, the likelihood of compromise increases. A compromised key set would allow an attacker to intercept and possibly inject comprised data into the DNS server. In this compromised state, the DNS server would be vulnerable to DoS attacks, as well as being vulnerable to becoming a launching pad for further attacks on an organizations network.",
|
|
218
|
+
"severity": "medium"
|
|
219
|
+
},
|
|
220
|
+
{
|
|
221
|
+
"id": "V-72445",
|
|
222
|
+
"title": "A BIND 9.x server must implement NIST FIPS-validated cryptography for provisioning digital signatures and generating cryptographic hashes.",
|
|
223
|
+
"description": "The use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.\n\nThe choice of digital signature algorithm will be based on recommended algorithms in well-known standards. NIST's Digital Signature Standard (DSS) [FIPS186] provides three algorithm choices:\n\n- Digital Signature Algorithm (DSA)\n- RSA\n- Elliptic Curve DSA (ECDSA)\n\nOf these three algorithms, RSA and DSA are more widely available and hence are 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. Hence, RSA is the recommended algorithm as far as this guideline is concerned. It can be expected that name servers and clients will be able to use the RSA algorithm at the minimum.\n\nNIST's Secure Hash Standard (SHS) (FIPS 180-3) specifies SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 as approved hash algorithms to be used as part of the algorithm suite for generating digital signatures using the digital signature algorithms in NIST's DSS[FIPS186].\n\nSatisfies: SRG-APP-000514-DNS-000075, SRG-APP-000516-DNS-000090",
|
|
224
|
+
"severity": "high"
|
|
225
|
+
},
|
|
226
|
+
{
|
|
227
|
+
"id": "V-72447",
|
|
228
|
+
"title": "The DNSSEC keys used with the BIND 9.x implementation must be owned by a privileged account.",
|
|
229
|
+
"description": "Information at rest refers to the state of information when it is located on a secondary storage device within an organizational information system. Mobile devices, laptops, desktops, and storage devices can be either lost or stolen, and the contents of their data storage (e.g., hard drives and non-volatile memory) can be read, copied, or altered. Applications and application users generate information throughout the course of their application use.\n\nThe DNS server must protect the confidentiality and integrity of the DNSSEC keys and must protect the integrity of DNS information. There is no need to protect the confidentiality of DNS information because it is accessible by all devices that can contact the server.",
|
|
230
|
+
"severity": "medium"
|
|
231
|
+
},
|
|
232
|
+
{
|
|
233
|
+
"id": "V-72449",
|
|
234
|
+
"title": "The DNSSEC keys used with the BIND 9.x implementation must be group owned by a privileged account.",
|
|
235
|
+
"description": "Information at rest refers to the state of information when it is located on a secondary storage device within an organizational information system. Mobile devices, laptops, desktops, and storage devices can be either lost or stolen, and the contents of their data storage (e.g., hard drives and non-volatile memory) can be read, copied, or altered. Applications and application users generate information throughout the course of their application use.\n\nThe DNS server must protect the confidentiality and integrity of the DNSSEC keys and must protect the integrity of DNS information. There is no need to protect the confidentiality of DNS information because it is accessible by all devices that can contact the server.",
|
|
236
|
+
"severity": "medium"
|
|
237
|
+
},
|
|
238
|
+
{
|
|
239
|
+
"id": "V-72451",
|
|
240
|
+
"title": "Permissions assigned to the DNSSEC keys used with the BIND 9.x implementation must enforce read-only access to the key owner and deny access to all other users.",
|
|
241
|
+
"description": "Information at rest refers to the state of information when it is located on a secondary storage device within an organizational information system. Mobile devices, laptops, desktops, and storage devices can be either lost or stolen, and the contents of their data storage (e.g., hard drives and non-volatile memory) can be read, copied, or altered. Applications and application users generate information throughout the course of their application use.\n\nThe DNS server must protect the confidentiality and integrity of the DNSSEC keys and must protect the integrity of DNS information. There is no need to protect the confidentiality of DNS information because it is accessible by all devices that can contact the server.",
|
|
242
|
+
"severity": "medium"
|
|
243
|
+
},
|
|
244
|
+
{
|
|
245
|
+
"id": "V-72453",
|
|
246
|
+
"title": "The BIND 9.x server private key corresponding to the ZSK pair must be the only DNSSEC key kept on a name server that supports dynamic updates.",
|
|
247
|
+
"description": "The private key in the ZSK key pair must be protected from unauthorized access. If possible, the private key should be stored off-line (with respect to the Internet-facing, DNSSEC-aware name server) in a physically secure, non-network-accessible machine along with the zone file master copy. \n\nThis strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) has to have both the zone file master copy and the private key corresponding to the zone-signing key (ZSK-private) online to immediately update the signatures for the updated RRsets.\n\nFailure to protect the private ZSK opens it to being maliciously obtained and opens the DNS zone to being populated with invalid data. The integrity of the DNS zone would be compromised leading to a loss of trust whether a DNS response has originated from an authentic source, the response is complete, and has not been tampered with during transit.",
|
|
248
|
+
"severity": "high"
|
|
249
|
+
},
|
|
250
|
+
{
|
|
251
|
+
"id": "V-72455",
|
|
252
|
+
"title": "On the BIND 9.x server the private keys corresponding to both the ZSK and the KSK must not be kept on the BIND 9.x DNSSEC-aware primary authoritative name server when the name server does not support dynamic updates.",
|
|
253
|
+
"description": "The private keys in the KSK and ZSK key pairs must be protected from unauthorized access. If possible, the private keys should be stored off-line (with respect to the Internet-facing, DNSSEC-aware name server) in a physically secure, non-network-accessible machine along with the zone file master copy. \n\nThis strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) has to have both the zone file master copy and the private key corresponding to the zone-signing key (ZSK-private) online to immediately update the signatures for the updated RRsets. The private key corresponding to the key-signing key (KSK-private) can still be kept off-line.",
|
|
254
|
+
"severity": "medium"
|
|
255
|
+
},
|
|
256
|
+
{
|
|
257
|
+
"id": "V-72457",
|
|
258
|
+
"title": "The two files generated by the BIND 9.x server dnssec-keygen program must be owned by the root account, or deleted, after they have been copied to the key file in the name server.",
|
|
259
|
+
"description": "To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key also can be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string that is generated by most key generation utilities used with DNSSEC is Base64-encoded. A TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message.",
|
|
260
|
+
"severity": "medium"
|
|
261
|
+
},
|
|
262
|
+
{
|
|
263
|
+
"id": "V-72459",
|
|
264
|
+
"title": "The two files generated by the BIND 9.x server dnssec-keygen program must be group owned by the server administrator account, or deleted, after they have been copied to the key file in the name server.",
|
|
265
|
+
"description": "To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key also can be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string that is generated by most key generation utilities used with DNSSEC is Base64-encoded. A TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message.",
|
|
266
|
+
"severity": "medium"
|
|
267
|
+
},
|
|
268
|
+
{
|
|
269
|
+
"id": "V-72461",
|
|
270
|
+
"title": "Permissions assigned to the dnssec-keygen keys used with the BIND 9.x implementation must enforce read-only access to the key owner and deny access to all other users.",
|
|
271
|
+
"description": "To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key also can be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string that is generated by most key generation utilities used with DNSSEC is Base64-encoded. A TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message. Weak permissions could allow an adversary to modify the file(s), thus defeating the security objective.",
|
|
272
|
+
"severity": "medium"
|
|
273
|
+
},
|
|
274
|
+
{
|
|
275
|
+
"id": "V-72469",
|
|
276
|
+
"title": "The BIND 9.x server signature generation using the KSK must be done off-line, using the KSK-private key stored off-line.",
|
|
277
|
+
"description": "The private key in the KSK key pair must be protected from unauthorized access. The private key should be stored off-line (with respect to the Internet-facing, DNSSEC-aware name server) in a physically secure, non-network-accessible machine along with the zone file master copy. \n\nFailure to protect the private KSK may have significant effects on the overall security of the DNS infrastructure. A compromised KSK could lead to an inability to detect unauthorized DNS zone data resulting in network traffic being redirected to a rogue site.",
|
|
278
|
+
"severity": "high"
|
|
279
|
+
},
|
|
280
|
+
{
|
|
281
|
+
"id": "V-72471",
|
|
282
|
+
"title": "A BIND 9.x server implementation must maintain the integrity and confidentiality of DNS information while it is being prepared for transmission, in transmission, and in use and t must perform integrity verification and data origin verification for all DNS information.",
|
|
283
|
+
"description": "DNSSEC is required for securing the DNS query/response transaction by providing data origin authentication and data integrity verification through signature verification and the chain of trust\n\nFailure to accomplish data origin authentication and data integrity verification could have significant effects on DNS Infrastructure. The resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service\n\nFailure to validate name server replies would cause many networking functions and communications to 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 subdomain, from the top of the DNS hierarchy down.\n\nFailure to validate the chain of trust used with DNSSEC would have a significant impact on the security posture of the DNS server. Non-validated trust chains may contain rouge DNS servers and allow those unauthorized servers to introduce invalid data into an organizations DNS infrastructure. A compromise of this type would be difficult to detect and may have devastating effects on the validity and integrity of DNS zone information.\n\nSatisfies: SRG-APP-000213-DNS-000024, SRG-APP-000215-DNS-000026, SRG-APP-000219-DNS-000028, SRG-APP-000219-DNS-000029, SRG-APP-000219-DNS-000030, SRG-APP-000347-DNS-000041, SRG-APP-000348-DNS-000042, SRG-APP-000349-DNS-000043, SRG-APP-000420-DNS-000053, SRG-APP-000421-DNS-000054, SRG-APP-000422-DNS-000055, SRG-APP-000423-DNS-000056, SRG-APP-000424-DNS-000057, SRG-APP-000425-DNS-000058, SRG-APP-000426-DNS-000059, SRG-APP-000441-DNS-000066, SRG-APP-000442-DNS-000067, SRG-APP-000516-DNS-000089",
|
|
284
|
+
"severity": "high"
|
|
285
|
+
},
|
|
286
|
+
{
|
|
287
|
+
"id": "V-72473",
|
|
288
|
+
"title": "A BIND 9.x server implementation must provide the means to indicate the security status of child zones.",
|
|
289
|
+
"description": "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 subdomain, from the top of the DNS hierarchy down.\n\nA 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.\n\nIn 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.\n\nA trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and Domain Name System Security Extensions (DNSSEC).\n\nWhen there is a chain of trust, usually the top entity to be trusted becomes the trust anchor. A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate. In DNS, a trust anchor is a DNSKEY that is placed into a validating resolver so the validator can cryptographically validate the results for a given request back to a known public key (the trust anchor).\n\nAn example means to indicate the security status of child subspaces is through the use of delegation signer (DS) resource records in the DNS.\n\nPath validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Without path validation and a chain of trust, there can be no trust that the data integrity authenticity has been maintained during a transaction.",
|
|
290
|
+
"severity": "medium"
|
|
291
|
+
},
|
|
292
|
+
{
|
|
293
|
+
"id": "V-72475",
|
|
294
|
+
"title": "The BIND 9.x server validity period for the RRSIGs covering the DS RR for zones delegated children must be no less than two days and no more than one week.",
|
|
295
|
+
"description": "The best way for a zone administrator to minimize the impact of a key compromise is by limiting the validity period of RRSIGs in the zone and in the parent zone. This strategy limits the time during which an attacker can take advantage of a compromised key to forge responses. An attacker that has compromised a ZSK can use that key only during the KSK's signature validity interval. An attacker that has compromised a KSK can use that key for only as long as the signature interval of the RRSIG covering the DS RR in the delegating parent. These validity periods should be short, which will require frequent re-signing.\n\nTo prevent the impact of a compromised KSK, a delegating parent should set the signature validity period for RRSIGs covering DS RRs in the range of a few days to 1 week. This re-signing does not require frequent rollover of the parent's ZSK, but scheduled ZSK rollover should still be performed at regular intervals.",
|
|
296
|
+
"severity": "medium"
|
|
297
|
+
},
|
|
298
|
+
{
|
|
299
|
+
"id": "V-72477",
|
|
300
|
+
"title": "The core BIND 9.x server files must be owned by the root or BIND 9.x process account.",
|
|
301
|
+
"description": "Discretionary Access Control (DAC) is based on the premise that individual users are \"owners\" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. In a DNS implementation, DAC should be granted to a minimal number of individuals and objects because DNS does not interact directly with users and users do not store and share data with the DNS application directly.",
|
|
302
|
+
"severity": "medium"
|
|
303
|
+
},
|
|
304
|
+
{
|
|
305
|
+
"id": "V-72479",
|
|
306
|
+
"title": "The core BIND 9.x server files must be group owned by a group designated for DNS administration only.",
|
|
307
|
+
"description": "Discretionary Access Control (DAC) is based on the premise that individual users are \"owners\" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. In a DNS implementation, DAC should be granted to a minimal number of individuals and objects because DNS does not interact directly with users and users do not store and share data with the DNS application directly.",
|
|
308
|
+
"severity": "medium"
|
|
309
|
+
},
|
|
310
|
+
{
|
|
311
|
+
"id": "V-72481",
|
|
312
|
+
"title": "The permissions assigned to the core BIND 9.x server files must be set to utilize the least privilege possible.",
|
|
313
|
+
"description": "Discretionary Access Control (DAC) is based on the premise that individual users are \"owners\" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. In a DNS implementation, DAC should be granted to a minimal number of individuals and objects because DNS does not interact directly with users and users do not store and share data with the DNS application directly.",
|
|
314
|
+
"severity": "medium"
|
|
315
|
+
},
|
|
316
|
+
{
|
|
317
|
+
"id": "V-72483",
|
|
318
|
+
"title": "On a BIND 9.x server for 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.",
|
|
319
|
+
"description": "Authoritative name servers for an enterprise may be configured to receive requests from both external and internal clients. \n\nExternal clients need to receive RRs that pertain only to public services (public Web server, mail server, etc.) \n\nInternal clients need to receive RRs pertaining to public services as well as internal hosts. \n\nThe 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).",
|
|
320
|
+
"severity": "medium"
|
|
321
|
+
},
|
|
322
|
+
{
|
|
323
|
+
"id": "V-72485",
|
|
324
|
+
"title": "On a BIND 9.x server in 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.",
|
|
325
|
+
"description": "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. \n\nOne 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.) \n\nThe 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.",
|
|
326
|
+
"severity": "medium"
|
|
327
|
+
},
|
|
328
|
+
{
|
|
329
|
+
"id": "V-72487",
|
|
330
|
+
"title": "On a BIND 9.x server in a split DNS configuration, where separate name servers are used between the external and internal networks, the internal name server must be configured to not be reachable from outside resolvers.",
|
|
331
|
+
"description": "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. \n\nOne 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.) \n\nThe 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.",
|
|
332
|
+
"severity": "medium"
|
|
333
|
+
},
|
|
334
|
+
{
|
|
335
|
+
"id": "V-72489",
|
|
336
|
+
"title": "A BIND 9.x server implementation must implement internal/external role separation.",
|
|
337
|
+
"description": "DNS servers with an internal role only process name/address resolution requests from within the organization (i.e., internal clients). DNS servers with an external role only process name/address resolution information requests from clients external to the organization (i.e., on the external networks, including the Internet). The set of clients that can access an authoritative DNS server in a particular role is specified by the organization using address ranges, explicit access control lists, etc. In order to protect internal DNS resource information, it is important to isolate the requests to internal DNS servers. \n\nFailure to separate internal and external roles in DNS may lead to address space that is private (e.g., 10.0.0.0/24) or is otherwise concealed by some form of Network Address Translation from leaking into the public DNS system. Allowing private IP space to leak into the public DNS system may provide a person with malicious intent the ability to footprint your network and identify potential attack targets residing on your private network.",
|
|
338
|
+
"severity": "high"
|
|
339
|
+
},
|
|
340
|
+
{
|
|
341
|
+
"id": "V-72491",
|
|
342
|
+
"title": "On the BIND 9.x server the IP address for hidden master authoritative name servers must not appear in the name servers set in the zone database.",
|
|
343
|
+
"description": "A hidden master authoritative server is an authoritative DNS server whose IP address does not appear in the name server set for a zone. All of the name servers that do appear in the zone database as designated name servers get their zone data from the hidden master via a zone transfer request. In effect, all visible name servers are actually secondary slave servers. This prevents potential attackers from targeting the master name server because its IP address may not appear in the zone database.",
|
|
344
|
+
"severity": "medium"
|
|
345
|
+
},
|
|
346
|
+
{
|
|
347
|
+
"id": "V-72493",
|
|
348
|
+
"title": "A BIND 9.x implementation operating in a split DNS configuration must be approved by the organizations Authorizing Official.",
|
|
349
|
+
"description": "BIND 9.x has implemented an option to use \"view\" statements to allow for split DNS architecture to be configured on a single name server. \n\nIf the split DNS architecture is improperly configured there is a risk that internal IP addresses and host names could leak into the external view of the DNS server. \n\nAllowing private IP space to leak into the public DNS system may provide a person with malicious intent the ability to footprint your network and identify potential attack targets residing on your private network.",
|
|
350
|
+
"severity": "high"
|
|
351
|
+
},
|
|
352
|
+
{
|
|
353
|
+
"id": "V-72495",
|
|
354
|
+
"title": "On the BIND 9.x server the private key corresponding to the ZSK, stored on name servers accepting dynamic updates, must be owned by root.",
|
|
355
|
+
"description": "The private ZSK key must be protected from unauthorized access.\n\nThis strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) has to have both the zone file master copy and the private key corresponding to the zone-signing key (ZSK-private) online to immediately update the signatures for the updated RRsets.",
|
|
356
|
+
"severity": "medium"
|
|
357
|
+
},
|
|
358
|
+
{
|
|
359
|
+
"id": "V-72497",
|
|
360
|
+
"title": "On the BIND 9.x server the private key corresponding to the ZSK, stored on name servers accepting dynamic updates, must be group owned by root.",
|
|
361
|
+
"description": "The private ZSK key must be protected from unauthorized access.\n\nThis strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) has to have both the zone file master copy and the private key corresponding to the zone-signing key (ZSK-private) online to immediately update the signatures for the updated RRsets.",
|
|
362
|
+
"severity": "medium"
|
|
363
|
+
},
|
|
364
|
+
{
|
|
365
|
+
"id": "V-72499",
|
|
366
|
+
"title": "A BIND 9.x server implementation must enforce approved authorizations for controlling the flow of information between authoritative name servers and specified secondary name servers based on DNSSEC policies.",
|
|
367
|
+
"description": "A mechanism to detect and prevent unauthorized communication flow must be configured or provided as part of the system design. If information flow is not enforced based on approved authorizations, the system may become compromised. Information flow control regulates where information is allowed to travel within a system and between interconnected systems. The flow of all application information must be monitored and controlled so it does not introduce any unacceptable risk to the systems or data.\n\nWithin the context of DNS, this is applicable in terms of controlling the flow of DNS information between systems, such as DNS zone transfers.\n\nAuthoritative name servers (especially primary name servers) should be configured with an allow-transfer access control sub statement designating the list of hosts from which DNS information, such as zone transfers, can be accepted. These restrictions address the denial-of-service threat and potential exploits from unrestricted dissemination of information about internal resources.\n\nZone transfer from primary name servers should be restricted to secondary name servers. The zone transfer should be completely disabled in the secondary name servers. The address match list argument for the allow-transfer sub statement should consist of IP addresses of secondary name servers and stealth secondary name servers.\n\nSatisfies: SRG-APP-000215-DNS-000003, SRG-APP-000516-DNS-000095",
|
|
368
|
+
"severity": "medium"
|
|
369
|
+
},
|
|
370
|
+
{
|
|
371
|
+
"id": "V-72501",
|
|
372
|
+
"title": "A BIND 9.x server validity period for the RRSIGs covering a zones DNSKEY RRSet must be no less than two days and no more than one week.",
|
|
373
|
+
"description": "The best way for a zone administrator to minimize the impact of a key compromise is by limiting the validity period of RRSIGs in the zone and in the parent zone. This strategy limits the time during which an attacker can take advantage of a compromised key to forge responses. An attacker that has compromised a ZSK can use that key only during the KSK's signature validity interval. An attacker that has compromised a KSK can use that key for only as long as the signature interval of the RRSIG covering the DS RR in the delegating parent. These validity periods should be short, which will require frequent re-signing.",
|
|
374
|
+
"severity": "medium"
|
|
375
|
+
},
|
|
376
|
+
{
|
|
377
|
+
"id": "V-72503",
|
|
378
|
+
"title": "A BIND 9.x server NSEC3 must be used for all internal DNS zones.",
|
|
379
|
+
"description": "To ensure that RRs associated with a query are really missing in a zone file and have not been removed in transit, the DNSSEC mechanism provides a means for authenticating the nonexistence of an RR. It generates a special RR called an NSEC (or NSEC3) RR that lists the RRTypes associated with an owner name as well as the next name in the zone file. It sends this special RR, along with its signatures, to the resolving name server. By verifying the signature, a DNSSEC-aware resolving name server can determine which authoritative owner name exists in a zone and which authoritative RRTypes exist at those owner names.",
|
|
380
|
+
"severity": "medium"
|
|
381
|
+
},
|
|
382
|
+
{
|
|
383
|
+
"id": "V-72505",
|
|
384
|
+
"title": "Every NS record in a zone file on a BIND 9.x server must point to an active name server and that name server must be authoritative for the domain specified in that record.",
|
|
385
|
+
"description": "Poorly constructed NS records pose a security risk because they create conditions under which an adversary might be able to provide the missing authoritative name services that are improperly specified in the zone file. The adversary could issue bogus responses to queries that clients would accept because they learned of the adversary's name server from a valid authoritative name server, one that need not be compromised for this attack to be successful. The list of slave servers must remain current within 72 hours of any changes to the zone architecture that would affect the list of slaves. If a slave server has been retired or is not operational but remains on the list, then an adversary might have a greater opportunity to impersonate that slave without detection, rather than if the slave were actually online. For example, the adversary may be able to spoof the retired slave's IP address without an IP address conflict, which would not be likely to occur if the true slave were active.",
|
|
386
|
+
"severity": "medium"
|
|
387
|
+
},
|
|
388
|
+
{
|
|
389
|
+
"id": "V-72507",
|
|
390
|
+
"title": "On a BIND 9.x server all authoritative name servers for a zone must be located on different network segments.",
|
|
391
|
+
"description": "Most enterprises have an authoritative primary server and a host of authoritative secondary name servers. It is essential that these authoritative name servers for an enterprise be located on different network segments. This dispersion ensures the availability of an authoritative name server not only in situations in which a particular router or switch fails but also during events involving an attack on an entire network segment.",
|
|
392
|
+
"severity": "medium"
|
|
393
|
+
},
|
|
394
|
+
{
|
|
395
|
+
"id": "V-72509",
|
|
396
|
+
"title": "On a BIND 9.x server all authoritative name servers for a zone must have the same version of zone information.",
|
|
397
|
+
"description": "It is important to maintain the integrity of a zone file. The serial number of the SOA record is used to indicate to secondary name server that a change to the zone has occurred and a zone transfer should be performed. The serial number used in the SOA record provides the DNS administrator a method to verify the integrity of the zone file based on the serial number of the last update and ensure that all slave servers are using the correct zone file.",
|
|
398
|
+
"severity": "medium"
|
|
399
|
+
},
|
|
400
|
+
{
|
|
401
|
+
"id": "V-72511",
|
|
402
|
+
"title": "On a BIND 9.x server all root name servers listed in the local root zone file hosted on a BIND 9.x authoritative name server must be valid for that zone.",
|
|
403
|
+
"description": "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.",
|
|
404
|
+
"severity": "low"
|
|
405
|
+
},
|
|
406
|
+
{
|
|
407
|
+
"id": "V-72513",
|
|
408
|
+
"title": "On a BIND 9.x server all root name servers listed in the local root zone file hosted on a BIND 9.x authoritative name server must be empty or removed.",
|
|
409
|
+
"description": "A potential vulnerability of DNS is that an attacker can poison a name servers 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. The DNS architecture needs to maintain one name server whose zone records are correct and the cache is not poisoned, in this effort the authoritative name server may not forward queries, one of the ways to prevent this, the root hints file is to be deleted.\n\nWhen 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 requirement 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.",
|
|
410
|
+
"severity": "low"
|
|
411
|
+
},
|
|
412
|
+
{
|
|
413
|
+
"id": "V-72515",
|
|
414
|
+
"title": "On the BIND 9.x server a zone file must not include resource records that resolve to a fully qualified domain name residing in another zone.",
|
|
415
|
+
"description": "If a name server were able to claim authority for a resource record in a domain for which it was not authoritative, this would pose a security risk. In this environment, an adversary could use illicit control of a name server to impact IP address resolution beyond the scope of that name server (i.e., by claiming authority for records outside of that server's zones). Fortunately, all but the oldest versions of BIND and most other DNS implementations do not allow for this behavior. Nevertheless, the best way to eliminate this risk is to eliminate from the zone files any records for hosts in another zone.",
|
|
416
|
+
"severity": "medium"
|
|
417
|
+
},
|
|
418
|
+
{
|
|
419
|
+
"id": "V-72517",
|
|
420
|
+
"title": "On the BIND 9.x server CNAME records must not point to a zone with lesser security for more than six months.",
|
|
421
|
+
"description": "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.",
|
|
422
|
+
"severity": "low"
|
|
423
|
+
},
|
|
424
|
+
{
|
|
425
|
+
"id": "V-72519",
|
|
426
|
+
"title": "The BIND 9.x server implementation must prohibit the forwarding of queries to servers controlled by organizations outside of the U.S. Government.",
|
|
427
|
+
"description": "If remote servers to which DoD DNS servers send queries are controlled by entities outside of the U.S. Government the possibility of a DNS attack is increased. \n\nThe Enterprise Recursive Service (ERS) provides the ability to apply enterprise-wide policy to all recursive DNS traffic that traverses the NIPRNet-to-Internet boundary. All recursive DNS servers on the NIPRNet must be configured to exclusively forward DNS traffic traversing NIPRNet-to-Internet boundary to the ERS anycast IPs.\n\nOrganizations need to carefully configure any forwarding that is being used by their caching name servers. They should only configure \"forwarding of all queries\" to servers within the DoD. Systems configured to use domain-based forwarding should not forward queries for mission critical domains to any servers that are not under the control of the US Government.",
|
|
428
|
+
"severity": "medium"
|
|
429
|
+
}
|
|
430
|
+
]
|
|
431
|
+
}
|
|
@@ -0,0 +1,317 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "stig_bind_dns",
|
|
3
|
+
"date": "2015-10-01",
|
|
4
|
+
"description": "None",
|
|
5
|
+
"title": "BIND DNS STIG",
|
|
6
|
+
"version": "None",
|
|
7
|
+
"item_syntax": "^\\w-\\d+$",
|
|
8
|
+
"section_separator": null,
|
|
9
|
+
"items": [
|
|
10
|
+
{
|
|
11
|
+
"id": "V-12440",
|
|
12
|
+
"title": "A unique TSIG key is not generated and utilized for each type of transaction. ",
|
|
13
|
+
"description": "To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key also can be used for securing other transactions, such as dynamic updates, DNS queries, and responses.",
|
|
14
|
+
"severity": "low"
|
|
15
|
+
},
|
|
16
|
+
{
|
|
17
|
+
"id": "V-12774",
|
|
18
|
+
"title": "The forwarding configuration of DNS servers must prohibit the forwarding of queries to servers controlled by organizations outside of the U.S. Government. ",
|
|
19
|
+
"description": "If remote servers to which DoD DNS servers send queries are controlled by entities outside of the U.S. Government the possibility of a DNS attack is increased. \n\nThe Enterprise Recursive Service (ERS) provides the ability to apply enterprise-wide policy to all recursive DNS traffic that traverses the NIPRNet-to-Internet boundary. All recursive DNS servers on the NIPRNet must be configured to exclusively forward DNS traffic traversing NIPRNet-to-Internet boundary to the ERS anycast IPs.\nOrganizations need to carefully configure any forwarding that is being used by their caching\nname servers. They should only configure \"forwarding of all queries\" to servers within the DoD.\nSystems configured to use domain-based forwarding should not forward queries for mission critical\ndomains to any servers that are not under the control of the US Government.",
|
|
20
|
+
"severity": "medium"
|
|
21
|
+
},
|
|
22
|
+
{
|
|
23
|
+
"id": "V-12966",
|
|
24
|
+
"title": "Inadequate file permissions on BIND name servers.",
|
|
25
|
+
"description": "Weak permissions could allow an intruder to view or modify zone, configuration and/or program files.",
|
|
26
|
+
"severity": "medium"
|
|
27
|
+
},
|
|
28
|
+
{
|
|
29
|
+
"id": "V-12967",
|
|
30
|
+
"title": "The SA has not configured BIND in a chroot(ed) directory structure.",
|
|
31
|
+
"description": "With any network service, there is the potential that an attacker can exploit a vulnerability within the program that allows the attacker to gain control of the process and even run system commands with that control. One possible defense against this attack is to limit the software to particular quarantined areas of the file system, memory or both. This effectively restricts the service so that it will not have access to the full file system. If such a defense were in place, then even if an attacker gained control of the process, the attacker would be unable to reach other commands or files on the system. This approach often is referred to as a padded cell, jail, or sandbox. All of these terms allude to the fact that the software is contained in an area where it cannot harm either itself or others. A more technical term is a chroot(ed) directory structure.\n\nBIND should be configured to run in a padded cell or chroot(ed) directory structure if supported by the operating system\n",
|
|
32
|
+
"severity": "low"
|
|
33
|
+
},
|
|
34
|
+
{
|
|
35
|
+
"id": "V-14756",
|
|
36
|
+
"title": "The DNS administrator will ensure non-routeable IPv6 link-local scope addresses are not configured in any zone. Such addresses begin with the prefixes of “FE8”, “FE9”, “FEA”, or “FEB”.",
|
|
37
|
+
"description": "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.",
|
|
38
|
+
"severity": "low"
|
|
39
|
+
},
|
|
40
|
+
{
|
|
41
|
+
"id": "V-14757",
|
|
42
|
+
"title": "AAAA addresses are configured on a host that is not IPv6 aware.",
|
|
43
|
+
"description": "DNS is only responsible for resolving a domain name to an ip address. Applications and operating systems are responsible for processing the IPv6 or IPv4 record that may be returned. With this in mind, a denial of service could easily be implemented for an application that is not IPv6 aware. When the application receives an i.p. address in hexadecimal, it is up to the application/operating system to decide how to handle the response. Combining both IPv6 and IPv4 records into the same domain can lead to application problems that are beyond the scope of the DNS administrator.",
|
|
44
|
+
"severity": "low"
|
|
45
|
+
},
|
|
46
|
+
{
|
|
47
|
+
"id": "V-14758",
|
|
48
|
+
"title": "The DNS software administrator will ensure the named.conf options statement does not include the option \"listen-on-v6 { any; };” when an IPv6 interface is not configured and enabled.",
|
|
49
|
+
"description": "To prevent the possibility of a denial of service in relation to an IPv4 DNS server trying to respond to an IPv6 request, 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.",
|
|
50
|
+
"severity": "medium"
|
|
51
|
+
},
|
|
52
|
+
{
|
|
53
|
+
"id": "V-14759",
|
|
54
|
+
"title": "The DNS administrator, when implementing DNSSEC, will create and maintain separate key-pairs for key signing and zone signing.",
|
|
55
|
+
"description": "DNSSEC specifies generation and verification of digital signatures using asymmetric keys. This requires generation of a public key-private key pair. Although the DNSSEC specification does not call for different keys (just one key pair), experience from pilot implementations suggests that for easier routine security administration operations such as key rollover (changing of keys) and zone re-signing, at least two different types of keys are needed.",
|
|
56
|
+
"severity": "low"
|
|
57
|
+
},
|
|
58
|
+
{
|
|
59
|
+
"id": "V-14760",
|
|
60
|
+
"title": "The DNSSEC algorithm for digital signatures must be RSASHA1, RSASHA256, or RSASHA512.",
|
|
61
|
+
"description": "MD5 is not collision resistant; therefore, RSAMD5 is not permitted for use in DNSSEC. RSASHA1 is the minimum algorithm for zone signatures. SHA2-based algorithms RSASHA256 and RSASHA512 offer greater security and are preferred over RSASHA1.",
|
|
62
|
+
"severity": "low"
|
|
63
|
+
},
|
|
64
|
+
{
|
|
65
|
+
"id": "V-14761",
|
|
66
|
+
"title": "The DNSSEC key signing key is not at least 2048 bits.\t\t",
|
|
67
|
+
"description": " The choice of key size is a tradeoff between the risk of key compromise and performance. The performance variables are signature generation and verification times. The size of the DNS response packet also is a factor because DNSKEY RRs may be sent in the additional section of the DNS response. Because the KSK is used only for signing the key set (DNSKEY RRSet), performance is not much of an issue. Compromise of a KSK could have a great impact, however, because the KSK is the entry point key for a zone. Rollover of a KSK in the event of a compromise involves potential update of trust anchors in many validating resolvers. Hence, a large key size is recommended for the KSK. A large key size decreases the chances of the key compromise and avoids the need for frequent rollovers as each rollover requires administrative monitoring and follow-up action.",
|
|
68
|
+
"severity": "low"
|
|
69
|
+
},
|
|
70
|
+
{
|
|
71
|
+
"id": "V-14762",
|
|
72
|
+
"title": "The DNSSEC key signing key does not have a minimum roll over period of one year.",
|
|
73
|
+
"description": "A good practice is to generate an extra set of key signing keys for rollover purposes. The additional key will be readily available for emergency situations such as key compromise. The key signing key should be rolled over on an annual basis.",
|
|
74
|
+
"severity": "low"
|
|
75
|
+
},
|
|
76
|
+
{
|
|
77
|
+
"id": "V-14764",
|
|
78
|
+
"title": "The DNSSEC zone signing key size is not at least 1024 bits.",
|
|
79
|
+
"description": "As far as the choice of key size for the ZSK is concerned, performance certainly will be a factor because the ZSK is used for signing all RRsets in the zone. In terms of impact, however, it is restricted to just a single zone because the ZSKs usage is limited to signing RRsets only for that zone but not for providing authenticated delegation for a child zone. Hence, a key size smaller than that for the KSK can be used for the ZSK.\n\n",
|
|
80
|
+
"severity": "low"
|
|
81
|
+
},
|
|
82
|
+
{
|
|
83
|
+
"id": "V-14765",
|
|
84
|
+
"title": "The DNSSEC zone signing key minimum roll over period is not at least 60 days.",
|
|
85
|
+
"description": "In the case of ZSK, the risk of key guessing is higher because of larger key exposure. The larger key exposure is a result of the fact that the number of signature sets generated is very large (because the ZSK signs all RRsets in a zone and other RRsets change much more frequently than DNSKEY RRsets, so the number of fresh signatures generated is high). This factor, combined with the relatively smaller size of the key, implies that ZSKs must be rolled over more frequently than KSKs (usually a month or two).",
|
|
86
|
+
"severity": "low"
|
|
87
|
+
},
|
|
88
|
+
{
|
|
89
|
+
"id": "V-14766",
|
|
90
|
+
"title": "The DNSSEC private key file is not owned by the DNS administrator or the permissions are not set to a minimum of 600.",
|
|
91
|
+
"description": "The private keys in the KSK and ZSK key pairs should be protected from unauthorized access. If possible, the private keys should be stored offline (with respect to the DNSSEC-aware name server) in a physically secure, non-network-accessible machine along with the zone file master copy. The signatures generated by using the private keys should be transferred to the primary authoritative name servers through a load process, using a dynamically established network connection (rather than a permanent network link).",
|
|
92
|
+
"severity": "high"
|
|
93
|
+
},
|
|
94
|
+
{
|
|
95
|
+
"id": "V-14767",
|
|
96
|
+
"title": "DNSSEC is not enabled for signing files between names servers with DNSSEC capabilities.",
|
|
97
|
+
"description": "A powerful feature of DNSSEC is the ability to sign record sets to ensure their integrity and authenticity throughout the DNS infrastructure and not just between the authoritative name server and its zone partner or local client. The advantages of this feature become apparent when DoD users wish to securely validate records from other organizations, including commercial vendors, business partners, and other Government agencies.",
|
|
98
|
+
"severity": "medium"
|
|
99
|
+
},
|
|
100
|
+
{
|
|
101
|
+
"id": "V-24997",
|
|
102
|
+
"title": "All DNS caching resolvers (A/K/A “recursive name servers”) will have port and Query ID randomization enabled for all DNS querypackets/frames. ",
|
|
103
|
+
"description": "DNS queries are normally conducted over UDP for performance reasons, although the protocol will fall back to TCP in certain cases. Unfortunately, the lack of a true bi-directional connection in UDP greatly simplifies certain attacks that involve forged packets. While the connectionless UDP is in use, DNS servers will typically treat the first DNS response that matches certain characteristics of the outgoing query as the true response, and act upon the information provided. The relevant characteristics for a valid or forged response are the query source port (usually an “ephemeral” port above 1024), the responding IP address, the DNS transaction ID, and the Question section of the outgoing query. In the DNS protocol specification, none of these are required to have a great degree of randomness or unpredictability which makes certain attacks possible. Eugene Kashpureff demonstrated a fairly simple but effective attack in 1997, which led to software improvements that included verification that information included in the response was in fact something for which the responding server should be trusted (referred to as “in bailiwick”).\n\nBecause this issue is fundamental to the DNS protocol over UDP, the IETF has devised the DNS Security Extensions (DNSSEC) and Transaction Authentication (TSIG) as protocol extensions to provide methods for cryptographic validation of data. TSIG has been widely adopted and has been a DNS STIG requirement for several years, but DNSSEC has only recently become sufficiently mature and supported to be suitable for operational deployment. Until DNSSEC is fully deployed, attacks on DNS-over-UDP, including cache poisoning attacks, will continue to be effective.\n",
|
|
104
|
+
"severity": "medium"
|
|
105
|
+
},
|
|
106
|
+
{
|
|
107
|
+
"id": "V-3617",
|
|
108
|
+
"title": "BIND is not configured to run as a dedicated non-privileged user account. BIND is running as a root user.",
|
|
109
|
+
"description": "If an intruder gains control of named (BIND), the intruder will acquire the privileges of the user ID under which it runs. Running as a non-privileged user account limits the extent of any breach. When BIND runs as root (the default) intruders gain full control of the system.",
|
|
110
|
+
"severity": "low"
|
|
111
|
+
},
|
|
112
|
+
{
|
|
113
|
+
"id": "V-3618",
|
|
114
|
+
"title": "A UNIX or UNIX-based name server is running unnecessary daemon/services and/or is configured to start an unnecessary daemon, service, or program upon boot up.",
|
|
115
|
+
"description": "Unnecessary software running on a name server could introduce security vulnerabilities that would be avoided if it were not present.",
|
|
116
|
+
"severity": "medium"
|
|
117
|
+
},
|
|
118
|
+
{
|
|
119
|
+
"id": "V-3619",
|
|
120
|
+
"title": "It is possible to obtain a command shell by logging on to the DNS user account.",
|
|
121
|
+
"description": "If an intruder gains access to a command shell, the intruder may be able to execute unauthorized commands.",
|
|
122
|
+
"severity": "low"
|
|
123
|
+
},
|
|
124
|
+
{
|
|
125
|
+
"id": "V-3620",
|
|
126
|
+
"title": "Permissions on critical UNIX name server files are not as restrictive as required.",
|
|
127
|
+
"description": "Weak permissions could allow an intruder to view or modify zone, configuration and/or program files.",
|
|
128
|
+
"severity": "medium"
|
|
129
|
+
},
|
|
130
|
+
{
|
|
131
|
+
"id": "V-3621",
|
|
132
|
+
"title": "ISC BIND is not configured to run as a dedicated non-privileged service user account.",
|
|
133
|
+
"description": "If an intruder gains control of named (BIND), then the intruder will acquire the privileges of the user ID under which it runs. Running as a non-privileged user account limits the extent of any breach. When BIND runs as SYSTEM (the default) intruders gain full control of the system.",
|
|
134
|
+
"severity": "medium"
|
|
135
|
+
},
|
|
136
|
+
{
|
|
137
|
+
"id": "V-3622",
|
|
138
|
+
"title": "The ISC BIND service user is a member of a group other than Everyone and Authenticated Users.",
|
|
139
|
+
"description": "Membership in configurable groups gives the BIND service user unnecessary privileges that could be used by an intruder to further breach name server security.",
|
|
140
|
+
"severity": "low"
|
|
141
|
+
},
|
|
142
|
+
{
|
|
143
|
+
"id": "V-3623",
|
|
144
|
+
"title": "The ISC BIND service does not have the appropriate user rights required for the proper configuration and security of ISC BIND.",
|
|
145
|
+
"description": "Having user rights beyond the minimum necessary gives the BIND service user unnecessary privileges that could be used by an intruder to further breach name server security.",
|
|
146
|
+
"severity": "low"
|
|
147
|
+
},
|
|
148
|
+
{
|
|
149
|
+
"id": "V-3624",
|
|
150
|
+
"title": "The appropriate encryption software is not correctly installed and configured on Windows ISC BIND name servers and it is required that in-band remote management be performed from hosts outside the enclave in which the name server resides.",
|
|
151
|
+
"description": "In administrative network traffic is in the clear between external clients and name servers, then there is significant potential that authorized individuals can intercept and view that traffic, which may contain passwords and other sensitive information.",
|
|
152
|
+
"severity": "medium"
|
|
153
|
+
},
|
|
154
|
+
{
|
|
155
|
+
"id": "V-3626",
|
|
156
|
+
"title": "The ownership and permissions on all Windows ISC BIND name servers are not as restrictive as required.",
|
|
157
|
+
"description": "Weak permissions could allow an intruder to view or modify zone, configuration and/or program files.",
|
|
158
|
+
"severity": "medium"
|
|
159
|
+
},
|
|
160
|
+
{
|
|
161
|
+
"id": "V-39138",
|
|
162
|
+
"title": "DNSSEC is not enabled for verifying signed files between names servers with DNSSEC capabilities.",
|
|
163
|
+
"description": "A powerful feature of DNSSEC is the ability to sign record sets to ensure their integrity and authenticity throughout the DNS infrastructure and not just between the authoritative name server and its zone partner or local client. The advantages of this feature become apparent when DoD users wish to securely validate records from other organizations, including commercial vendors, business partners, and other Government agencies.",
|
|
164
|
+
"severity": "medium"
|
|
165
|
+
},
|
|
166
|
+
{
|
|
167
|
+
"id": "V-4467",
|
|
168
|
+
"title": "Record owners will validate their zones no less than annually. The DNS database administrator will remove all zone records that have not been validated in over a year. ",
|
|
169
|
+
"description": "If zone information has not been validated in over a year, then there is no assurance that it is still valid. If invalid records are in a zone, then an adversary could potentially use their existence for improper purposes. An SOP detailing this process can resolve this requirement.\n",
|
|
170
|
+
"severity": "low"
|
|
171
|
+
},
|
|
172
|
+
{
|
|
173
|
+
"id": "V-4468",
|
|
174
|
+
"title": "Resource records for a host in a zone file are included and their fully qualified domain name resides in another zone. The exception is a glue record or CNAME record supporting a system migration.",
|
|
175
|
+
"description": " If a name server were able to claim authority for a resource record in a domain for which it was not authoritative, this would pose a security risk. In this environment, an adversary could use illicit control of a name server to impact IP address resolution beyond the scope of that name server (i.e., by claiming authority for records outside of that servers zones). Fortunately, all but the oldest versions of BIND and most other DNS implementations do not allow for this behavior. Nevertheless, the best way to eliminate this risk is to eliminate from the zone files any records for hosts in another zone. The two key exceptions to this rule involve glue for NS records and CNAME records for legacy resolution support",
|
|
176
|
+
"severity": "low"
|
|
177
|
+
},
|
|
178
|
+
{
|
|
179
|
+
"id": "V-4469",
|
|
180
|
+
"title": "Zone-spanning CNAME records, that point to a zone with lesser security, are active for more than six months. ",
|
|
181
|
+
"description": "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 aliases 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 compounding the vulnerability.",
|
|
182
|
+
"severity": "low"
|
|
183
|
+
},
|
|
184
|
+
{
|
|
185
|
+
"id": "V-4470",
|
|
186
|
+
"title": "The DNS database administrator has not ensured each NS record in a zone file points to an active name server authoritative for the domain specified in that record.",
|
|
187
|
+
"description": "Poorly constructed NS records pose a security risk because they create conditions under which an adversary might be able to provide the missing authoritative name services that are improperly specified in the zone file. The adversary could issue bogus responses to queries that clients would accept because they learned of the adversary’s name server from a valid authoritative name server, one that need not be compromised for this attack to be successful.\n\nThe list of slave servers must remain current within 72 hours of any changes to the zone architecture that would affect the list of slaves. If a slave server has been retired or is not operational but remains on the list, then an adversary might have a greater opportunity to impersonate that slave without detection, rather than if the slave were actually online. For example, the adversary may be able to spoof the retired slave’s IP address without an IP address conflict, which would likely not occur if the true slave were active.\n",
|
|
188
|
+
"severity": "high"
|
|
189
|
+
},
|
|
190
|
+
{
|
|
191
|
+
"id": "V-4473",
|
|
192
|
+
"title": "DNS software does not run on dedicated (running only those services required for DNS) hardware. The only currently accepted exception of this requirement is Windows 2000/2003 DNS, which must run on a domain controller that is integrated with Active Directory services.\n\n",
|
|
193
|
+
"description": "Even a securely configured operating system is vulnerable to the flaws of the programs that run on it. To prevent DNS software from being subjected to the vulnerabilities of other programs and services, the DNS server will not run other programs and services at all, or at least run only those programs that are necessary for either OS or DNS support.",
|
|
194
|
+
"severity": "medium"
|
|
195
|
+
},
|
|
196
|
+
{
|
|
197
|
+
"id": "V-4475",
|
|
198
|
+
"title": "Permissions on files containing DNS encryption keys are inadequate.",
|
|
199
|
+
"description": "Weak permissions could allow an intruder to view or modify DNS encryption key files. These keys should never be readable by Other or Everyone.",
|
|
200
|
+
"severity": "medium"
|
|
201
|
+
},
|
|
202
|
+
{
|
|
203
|
+
"id": "V-4476",
|
|
204
|
+
"title": "Users and/or processes other than the DNS software Process ID (PID) and/or the DNS database administrator have edit/write access to the zone database files.",
|
|
205
|
+
"description": "Weak permissions on key files could allow an intruder to view or modify DNS zone files. Permissions on these files will be 640 or more restrictive. ",
|
|
206
|
+
"severity": "medium"
|
|
207
|
+
},
|
|
208
|
+
{
|
|
209
|
+
"id": "V-4477",
|
|
210
|
+
"title": "Users or processes other than the DNS software administrator and the DNS software PID have write access to these files. ",
|
|
211
|
+
"description": "Weak permissions on key DNS configuration files could allow an intruder to view or modify DNS name server configuration files.",
|
|
212
|
+
"severity": "medium"
|
|
213
|
+
},
|
|
214
|
+
{
|
|
215
|
+
"id": "V-4478",
|
|
216
|
+
"title": "The name server’s IP address is NOT statically defined and configured locally on the server. The name server has a DHCP address. ",
|
|
217
|
+
"description": "Static IP addresses permit a machine to offer Internet services like web, ftp, DNS, and email. Because a specific, known address is associated with your connection, other machines on the Internet know where to send traffic destined for your server. Required ACL restrictions at the router and or firewall are required to protect the DNS server from unauthorized access. Such ACLS require a static IP address to be effective.",
|
|
218
|
+
"severity": "medium"
|
|
219
|
+
},
|
|
220
|
+
{
|
|
221
|
+
"id": "V-4479",
|
|
222
|
+
"title": "An integrity checking tool is not installed or not monitoring for modifications to the root.hints and named.conf files.\n\n",
|
|
223
|
+
"description": "An integrity checking tool compares file and directory integrity to the baseline. It can alert the system administrator to unauthorized changes in files or directories. Unauthorized changes in files and directories can give a user unauthorized access to system resources. Undetected changes to DNS name server root hints and configuration files is the single greatest risk to the security and stability of the DNS name server. An integrity checking tool (e.g., Tripwire) aids in effectively monitoring and controlling changes to ensure improved security and system availability. This applies to both authoritative and caching name servers.",
|
|
224
|
+
"severity": "medium"
|
|
225
|
+
},
|
|
226
|
+
{
|
|
227
|
+
"id": "V-4480",
|
|
228
|
+
"title": "A cryptographic key used to secure DNS transactions has been utilized on a name server for more than one year.",
|
|
229
|
+
"description": "Keys are more likely to be compromised if they remain in use for over a year.",
|
|
230
|
+
"severity": "medium"
|
|
231
|
+
},
|
|
232
|
+
{
|
|
233
|
+
"id": "V-4481",
|
|
234
|
+
"title": "Dynamic updates are not cryptographically authenticated.",
|
|
235
|
+
"description": "The dynamic update capability has considerable appeal in an environment in which IP addresses change so frequently that it would be unacceptably burdensome or expensive to dedicate the time of a DNS database administrator to this function. This condition would likely be met at sites that rely on the Dynamic Host Configuration Protocol (DHCP) to assign IP addresses to client devices such as workstations, laptops, and IP telephones. It would also apply to sites that utilize frequently changing service (SRV) records.\n\nOn the other hand, dynamic updates can pose a security risk if the proper security controls are not implemented. When dynamic updates are permitted without any mitigating controls, a host with network access to the name server can modify any zone record with an appropriately crafted dynamic update request. \n\nThe solution is to require cryptographic authentication of all dynamic update requests, but not all DNS software supports this functionality. ",
|
|
236
|
+
"severity": "high"
|
|
237
|
+
},
|
|
238
|
+
{
|
|
239
|
+
"id": "V-4482",
|
|
240
|
+
"title": "The DNS software administrator will configure each master/slave server supporting a zone to cryptographically authenticate zone transfers.",
|
|
241
|
+
"description": "A slave updates its zone information by requesting a zone transfer from its master. In this transaction, the risk for the slave is that the response to its request is not in fact from its authorized master but from an adversary posing as the master. In this scenario, such an adversary would be able to modify and insert records into the slaves zone at will. To protect against this occurrence, the slave must be able to authenticate the master to provide assurance that any zone updates are valid.",
|
|
242
|
+
"severity": "high"
|
|
243
|
+
},
|
|
244
|
+
{
|
|
245
|
+
"id": "V-4483",
|
|
246
|
+
"title": "A zone master server does not limit zone transfers to a list of active slave name servers authoritative for that zone.",
|
|
247
|
+
"description": "The risk to the master in this situation, is that it would honor a request from a host that is not an authorized slave, but rather an adversary seeking information about the zone. To protect against this possibility, the master must first have knowledge of what machines are authorized slaves.",
|
|
248
|
+
"severity": "medium"
|
|
249
|
+
},
|
|
250
|
+
{
|
|
251
|
+
"id": "V-4485",
|
|
252
|
+
"title": "A name server is not configured to only accept notifications of zone changes from a host authoritative for that zone.",
|
|
253
|
+
"description": "A slave updates its zone information by requesting a zone transfer from its master. In this transaction, the risk for the slave is that the response to its request is not in fact from its authorized master but from an adversary posing as the master. In this scenario, such an adversary would be able to modify and insert records into the slaves zone at will. To protect against this occurrence, the slave must be able to authenticate the master to provide assurance that any zone updates are valid.",
|
|
254
|
+
"severity": "medium"
|
|
255
|
+
},
|
|
256
|
+
{
|
|
257
|
+
"id": "V-4486",
|
|
258
|
+
"title": "Recursion is not prohibited on an authoritative name server.",
|
|
259
|
+
"description": "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.\n\nTo 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.",
|
|
260
|
+
"severity": "medium"
|
|
261
|
+
},
|
|
262
|
+
{
|
|
263
|
+
"id": "V-4487",
|
|
264
|
+
"title": "A caching name server does not restrict recursive queries to only the IP addresses and IP address ranges of known supported clients.",
|
|
265
|
+
"description": "Any host that can query a resolving name server has the potential to poison the servers name cache or take advantage of other vulnerabilities that may be accessed through the query service. The best way to prevent this type of attack is to limit queries to internal hosts, which need to have this service available to them.",
|
|
266
|
+
"severity": "medium"
|
|
267
|
+
},
|
|
268
|
+
{
|
|
269
|
+
"id": "V-4488",
|
|
270
|
+
"title": "The DNS software must log success and failure events when starting and stopping of the name server service daemon, zone transfers, zone update notifications, and dynamic updates. ",
|
|
271
|
+
"description": "Logging must be comprehensive to be useful for both intrusion monitoring and security investigations. Setting logging at the severity notice should capture most relevant events without requiring unacceptable levels of data storage. The severity levels info and debug are also available to organizations that require additional logging for certain events or applications.",
|
|
272
|
+
"severity": "high"
|
|
273
|
+
},
|
|
274
|
+
{
|
|
275
|
+
"id": "V-4489",
|
|
276
|
+
"title": "The DNS software administrator has not configured 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.",
|
|
277
|
+
"description": "On name servers, DNS log data is typically more sensitive than system log data and, consequently, should benefit from security controls at least as restrictive as those for the system logging facility. DNS software administrators require 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 in order for them to be examined at a future time. Furthermore, it is required that the logs be reviewed daily.",
|
|
278
|
+
"severity": "medium"
|
|
279
|
+
},
|
|
280
|
+
{
|
|
281
|
+
"id": "V-4490",
|
|
282
|
+
"title": "Entries in the name server logs do not contain timestamps and severity information.",
|
|
283
|
+
"description": "Forensic analysis of security incidents and day-to-day monitoring are substantially more difficult if there are no timestamps on log entries.",
|
|
284
|
+
"severity": "low"
|
|
285
|
+
},
|
|
286
|
+
{
|
|
287
|
+
"id": "V-4492",
|
|
288
|
+
"title": "The DNS software administrator has not removed the root hints file on an authoritative name server in order for it to resolve only those records for which it is authoritative, and ensure that all other queries are refused.",
|
|
289
|
+
"description": "A potential vulnerability of DNS is that an attacker can poison a name servers 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. The DNS architecture needs to maintain one name server whose zone records are correct and the cache is not poisoned, in this effort the authoritative name server may not forward queries, one of the ways to prevent this, the root hints file is to be deleted.\nWhen 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 requirement 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.",
|
|
290
|
+
"severity": "low"
|
|
291
|
+
},
|
|
292
|
+
{
|
|
293
|
+
"id": "V-4493",
|
|
294
|
+
"title": "The DNS software administrator has not utilized at least 160 bit HMAC-SHA1 keys if available.",
|
|
295
|
+
"description": "SHA-1 is the algorithm currently specified in the National Institute of Standards and Technology's (NISTs) Secure Hashing Standard (FIPS 180-1) and required throughout DoD. HMAC-MD5 will be replaced with HMAC-SHA1 or higher when available for DNS TSIG applications. In general, only NIST or National Security Agency (NSA) approved algorithms should be utilized in the DoD computing infrastructure. The US Government currently requires SHA-1 for hashing applications. It is considered an improvement over MD5, for which there are known instances of collisions.",
|
|
296
|
+
"severity": "low"
|
|
297
|
+
},
|
|
298
|
+
{
|
|
299
|
+
"id": "V-4494",
|
|
300
|
+
"title": "A TSIG key is not in its own dedicated file.",
|
|
301
|
+
"description": "Ideally, nobody even DNS and Systems Administrators should view the key. If it is included in named.conf, they will view it on a regular basis, which means computer forensics is less likely to determine who may have obtained the key if it is compromised. In addition, if the named.conf needs to be copied from the system for whatever reason (e.g., sent to an expert to troubleshoot a problem, appended to a change management work order, etc.), then others will see the key and could copy it. On the other hand, if the key is in a dedicated file, then the operating system can be configured to log any instance when the key is accessed, which would make it easy for security personnel to determine when users other than the DNS name server software performed this function.",
|
|
302
|
+
"severity": "medium"
|
|
303
|
+
},
|
|
304
|
+
{
|
|
305
|
+
"id": "V-4495",
|
|
306
|
+
"title": "A unique TSIG key is not utilized for communication between name servers sharing zone information.",
|
|
307
|
+
"description": "If a secret key shared between two servers is not unique, then any breach of the key is not limited to those two servers. In particular, if all servers in a zone share the same key, then there is the possibility that an attack could modify records all of the servers. Recovering from a successful attack is considerably more difficult in this circumstance. Furthermore, the more copies of any one key are in existence, the greater the likelihood that the confidentiality of that key will be lost at some point in time.",
|
|
308
|
+
"severity": "medium"
|
|
309
|
+
},
|
|
310
|
+
{
|
|
311
|
+
"id": "V-4511",
|
|
312
|
+
"title": "A BIND name server is not configured to accept control messages only when the control messages are cryptographically authenticated and sent from an explicitly defined list of DNS administrator workstations. ",
|
|
313
|
+
"description": "The controls statement and the associated use of the rndc or ndc commands introduces the risk that an adversary could use them to remotely control the name server without having to authenticate to the operating system on which the name server resides.",
|
|
314
|
+
"severity": "medium"
|
|
315
|
+
}
|
|
316
|
+
]
|
|
317
|
+
}
|