OpenControls Logo

STIG Viewer

STIGViewer Support

The host running a BIND 9.x implementation must implement a set of firewall rules that restrict traffic on the DNS interface.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-272416BIND-9X-001630SV-272416r1156959_ruleCCI-000366medium
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. The 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.
STIGDate
BIND 9.x Security Technical Implementation Guide2026-02-25

Related Frameworks

1 mapping across 5 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (8) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

CFG-01Configuration Management Program
1.00
END-01Endpoint Device Management (EDM)
1.00
END-04Malicious Code Protection (Anti-Malware)
1.00
END-06Endpoint File Integrity Monitoring (FIM)
1.00
MON-01Continuous Monitoring
1.00
MON-01.7File Integrity Monitoring (FIM)
1.00
CFG-02Secure Baseline Configurations
0.50
CFG-02.7Approved Configuration Deviations
0.50
NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (100) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

AC-12Session Termination
1.00
AC-16(1)Dynamic Attribute Association
1.00
AC-17(1)Monitoring and Control
1.00
AC-2Account Management
1.00
AC-2(1)Automated System Account Management
1.00
AC-2(11)Usage Conditions
1.00
AC-2(3)Disable Accounts
1.00
AC-2(4)Automated Audit Actions
1.00
AC-24(1)Transmit Access Authorization Information
1.00
AC-25Reference Monitor
1.00

+90 more (top 10 by confidence shown)

NIST 800-1710 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (2) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

3.4.1
1.00
3.4.2
1.00
CCI1 mapping
CCI-000366
1.00
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (5) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

DE.CM-09
1.00
PR.PS-01
1.00
PR.DS-10
0.50
PR.PSPlatform Security
0.50
PR.PS-05
0.50

Who does this work

10 NICE work roles and 9 EC-Council certifications.

This is an inference across published mappings, not a single claim by anyone. This check maps to a control, which maps to a Cybersecurity Framework outcome, which NIST assigns to the work roles below. EC-Council separately maps its certifications to those same roles.

A certification prepares someone for a role. It is not evidence that a holder is qualified, and neither NIST nor EC-Council has stated that any certification here addresses this check.

Work-role assignments published by NIST (NICE Framework Components 2.2.0 and the CSF 2.0 OLIR crosswalk). Certification mappings published by EC-Council.

Details

Check Text (C-272416r1156959_chk)

With the assistance of the DNS administrator, verify that the OS firewall is configured to only allow incoming messages on ports 53/tcp and 53/udp. Note: The following rules are for the IPTables firewall. If the system is using a different firewall, the rules may be different. Inspect the hosts firewall rules for the following rules: -A INPUT -i [DNS Interface] -p tcp --dport 53 -j ACCEPT -A INPUT -i [DNS Interface] -p udp --dport 53 -j ACCEPT -A INPUT -i [DNS Interface] -j DROP If any of the above rules do not exist, this is a finding. If rules are listed that allow traffic on ports other than 53/tcp and 53/udp, this is a finding.

Fix Text (F-76373r1123928_fix)

Configure the OS firewall to only allow incoming DNS traffic on ports 53/tcp and 53/udp. Add the following rules to the host firewall rule set: # iptables -A INPUT -i [DNS Interface] -p tcp --dport 53 -j ACCEPT # iptables -A INPUT -i [DNS Interface] -p udp --dport 53 -j ACCEPT # iptables -A INPUT -i [DNS Interface] -j DROP Note: If the system is not using an IPTables firewall, the appropriate firewall rules that limit traffic to ports 53/tcp and 53/udp must be configured on the active firewall.