D3-ITF Inbound Traffic Filtering: Default Deny Ingress Rules and How to Test Them

Every service reachable from an untrusted network is part of the attack surface, and inbound traffic filtering is the control that decides which of those services are reachable at all. MITRE D3FEND names this countermeasure Inbound Traffic Filtering (D3-ITF) and defines it as "Restricting network traffic originating from untrusted networks destined towards a private host or enclave." It sits under the Isolate tactic as a child of Network Traffic Filtering (D3-NTF), with Email Filtering (D3-EF) as its own child. This card covers what D3FEND says about the technique, the ATT&CK techniques D3FEND relates to it, where it is implemented on hosts, network edges and cloud platforms, and how to prove the filters do what the rule set claims. It is written for network and platform engineers and for detection teams who test controls. Firewall operations as a discipline are covered in the Firewall Management Guide; this page stays on the D3FEND technique and its verification.

Key takeaways

• Default deny is the technique. Inbound filtering only isolates when unsolicited traffic is dropped unless a rule allows it. Windows Firewall, Azure network security groups, AWS security groups and Google Cloud VPC firewall rules all start from that position for inbound traffic; the risk comes from the allow rules added later.
• Port is not protocol. D3FEND's own considerations warn that protocols on non-standard ports can get past filters that do not identify the application from traffic content.
• Anti-spoofing is part of it. D3FEND lists blocking inbound packets that carry spoofed internal addresses as an example filter, the same idea BCP 38 (RFC 2827) asks network providers to apply at the edge.
• The ATT&CK mapping is inferred. D3FEND relates D3-ITF to phishing, public-facing application exploitation, local email collection and denial of service techniques through inferred, experimental relationships; treat them as orientation, not coverage.
• Verification is an outside-in scan plus log review. The rule base says what should happen; an external scan and the drop logs show what does happen.

D3-ITF at a glance

How it works

D3FEND defines inbound traffic as traffic from an untrusted network towards a private host or enclave, with two examples: an untrusted host connecting to an internal commercial portal, and an external mail server connecting to an internal mail server. Administrators write filtering policies to meet business requirements and limit connectivity, and enforce them on edge devices such as firewalls, routers and intrusion prevention systems. D3FEND lists four example filters:

• Anti-spoofing: block incoming traffic that carries internally facing IP addresses as its source. BCP 38 (RFC 2827, updated by RFC 3704 for multihomed networks) asks providers to drop traffic whose source address falls outside the prefixes legitimately behind an interface, and to log the drops. On BSD, the pf antispoof keyword generates such block rules for an interface's own network.
• Port and service blocking: stop specific ports and services from accepting connections.
• Source restriction: limit which IP ranges may connect, for example only a partner range or a management network.
• Dynamic inbound filtering: D3FEND names hole punching, STUN and NAT-T. These open short-lived inbound paths tied to an outbound session, which is also how stateful firewalls allow reply traffic without a standing inbound rule.

Stateful inspection is what makes default deny practical. Each of the cloud platforms in the next table documents stateful behaviour: return traffic for an allowed connection is permitted without a matching inbound rule. The inbound rule set therefore only has to describe connections that external parties are allowed to start.

Default inbound posture by implementation

Platforms are listed alphabetically. Each row states the documented starting point; rules added later change it.

Two of these (Linux Netfilter and pf) start open until the administrator writes a default deny. That makes "is there a final drop" the first question in any review of a Linux or BSD host.

ATT&CK techniques D3FEND relates to D3-ITF

Relationship type: inferred only. The D3FEND page for D3-ITF lists the techniques below and describes the mappings as inferred and experimental (D3FEND knowledge graph 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.

NHI Mgmt Group view, not part of D3FEND: the practical value of inbound filtering is larger than this list. Reducing exposed services shrinks the surface for T1190 Exploit Public-Facing Application (listed by D3FEND above) and for T1133 External Remote Services (not listed by D3FEND), and source restriction on management interfaces is often the difference between a vulnerable service that is reachable and one that is not. Denial of service context is in the MITRE ATT&CK T1498 Network Denial of Service page and the DDoS Protection Guide.

Where it is implemented

Host and network layers complement each other: the perimeter decides what reaches the enclave, the host decides what reaches the service. See the Host-Based Firewall Guide and the Linux Firewall Guide for host detail, and the Network Segmentation Guide for enclave design.

Where identity fits

Inbound rules increasingly carry identity context: cloud firewall rules that target service accounts or tags, and management ports opened only to a bastion. Two cautions apply. Source IP is not identity, so an allow rule for a partner range trusts every system in that range. And API endpoints exposed to the internet for automation are reached with tokens and keys, so inbound filtering on those endpoints limits where a stolen key can be used from. Pair it with the controls in the Least Privilege Techniques Guide.

Implementation steps

1. Inventory exposure first. List every public IP, load balancer, published service and cloud security rule with an internet source. An external scan of your own ranges, run with authorisation, is the baseline.
2. Set the default. Confirm a final deny for inbound traffic at each layer: a policy drop input chain on Linux, block all on pf, inbound block enabled on all three Windows Firewall profiles, no broad allow rules overriding cloud defaults.
3. Write allow rules from business need. D3FEND's considerations say business requirements drive rule sets. Each allow rule should carry an owner, a ticket reference and a review date, and name the narrowest source possible.
4. Add anti-spoofing. Drop inbound packets with internal, loopback or unallocated source addresses at the edge, and ask upstream providers how they apply BCP 38.
5. Turn on logging before enforcing changes. On Windows, enable "Log dropped packets" and "Log successful connections" per profile (Firewall CSP settings EnableLogDroppedPackets and EnableLogSuccessConnections); Microsoft recommends a log size of at least 20,480 KB. On cloud platforms enable flow or firewall rule logging selectively, since it can add cost. Azure documents that NSG flow logs retire on 30 September 2027 in favour of virtual network flow logs.
6. Change in stages. Apply a tightened rule set to a pilot segment or a staging copy of the cloud policy, watch drop logs for legitimate traffic, then roll out. Keep the previous rule set exported so rollback is a single re-import, and remember that on Azure removing a rule affects only new connections.
7. Review on a schedule. Remove rules with no hits over a defined period and expire temporary rules automatically. The Firewall Rule Review Checklist gives a review routine.

How to verify it works

• Outside-in scan: scan your public ranges from an external, authorised source on a schedule and compare open ports with the approved exposure list. Any difference is either an undocumented rule or a misattached one.
• Spoofing test: from an authorised test point outside the edge, send traffic claiming an internal source address and confirm it is dropped and logged.
• Drop log review: confirm drop records arrive in the SIEM. On Windows, event 5157 ("The Windows Filtering Platform has blocked a connection", subcategory Audit Filtering Platform Connection) and the firewall log file give host-level evidence; cloud flow logs give the same for security groups.
• Configuration drift checks: query cloud policies for inbound rules with source 0.0.0.0/0 or ::/0 on administrative ports such as 22 and 3389, and for host firewalls with a disabled profile.
• Tamper alerts: alert on attempts to disable or change firewall configuration, mapped to MITRE ATT&CK T1686 Disable or Modify System Firewall.

Limits, bypasses and failure patterns

• Allowed means exposed: filtering does nothing for a vulnerable service on an allowed port. Patch and harden what remains open.
• Non-standard ports: D3FEND notes that protocols on non-standard ports may get past filters that do not detect the application from content. Application identification or a proxy closes part of that gap.
• Encrypted and tunnelled traffic: traffic inside an allowed TLS or VPN session is invisible to a port filter; see D3-ET Encrypted Tunnels for the other side of that trade-off.
• Broad temporary rules: "any to any" rules added during an incident or migration and never removed.
• Inside threats: inbound filtering at the perimeter does not stop lateral movement from a host already inside; that needs segmentation and host firewalls.
• Volumetric floods: dropping traffic at your edge does not help when the link itself is full; that is a provider or scrubbing service decision.

Framework mapping

Related countermeasures

• Network Traffic Filtering (D3-NTF): the parent, covering traffic from any location. See D3-NTF Network Traffic Filtering.
• Outbound Traffic Filtering (D3-OTF): the egress counterpart. See D3-OTF Outbound Traffic Filtering.
• Email Filtering (D3-EF): the child technique for inbound mail. See D3-EF Email Filtering.
• Inbound Session Volume Analysis (D3-ISVA): a detection technique that watches what inbound filtering lets through. See D3-ISVA Inbound Session Volume Analysis.

Practitioner checklist

• Confirm a final inbound deny at every layer, especially on Linux and BSD hosts where none exists by default.
• Keep an approved exposure list and compare it with an external scan on a schedule.
• Give every inbound allow rule an owner, a business reason and a review date.
• Drop spoofed internal and reserved source addresses at the edge.
• Restrict administrative ports (22, 3389) to management networks or a bastion, never any source.
• Enable drop logging on host firewalls and flow logging on cloud networks, and confirm the logs reach the SIEM.
• Export the current rule set before every change so rollback is immediate.
• Alert on firewall disablement and rule changes outside change windows.
• Remove unused and expired temporary rules every review cycle.

Standards and references

• MITRE D3FEND: Inbound Traffic Filtering (D3-ITF)
• NIST: SP 800-41 Rev. 1 Guidelines on Firewalls and Firewall Policy
• IETF: RFC 2827 (BCP 38) Network Ingress Filtering
• Microsoft Learn: Windows Firewall overview
• Microsoft Learn: Configure Windows Firewall logging
• Microsoft Learn: Event 5157, the Windows Filtering Platform has blocked a connection
• nftables wiki: Simple ruleset for a server
• OpenBSD: pf.conf manual page
• AWS: Control traffic to your AWS resources using security groups
• Microsoft Learn: Azure network security groups overview
• Google Cloud: VPC firewall rules

Related NHI Mgmt Group resources: Firewall Management Guide · Host-Based Firewall Guide · M1037 Filter Network Traffic · Network Segmentation Guide · MITRE D3FEND Guide