Ingress and egress filtering block packets with spoofed source addresses from entering or leaving a network. In DNS security, these controls are critical because they stop attackers from forging the victim IP address needed to redirect amplified responses away from the real requester.
Expanded Definition
Ingress and egress filtering are network boundary controls that reject packets with spoofed source addresses, either as they enter a network or as they leave it. In NHI and DNS security, the purpose is not only to reduce spoofing but to deny attackers the forged victim address needed for reflection and amplification attacks. Guidance varies by environment, but the core idea is consistent with NIST Cybersecurity Framework 2.0 expectations for protective network controls and resilient communications.
In practice, ingress filtering checks whether incoming traffic could plausibly originate from the claimed source, while egress filtering prevents compromised internal hosts from emitting packets with deceptive source addresses. This distinction matters in NHI-heavy environments because service accounts, APIs, and automation often communicate at machine speed across segmented networks. When implemented well, these filters support Zero Trust Architecture by reducing the trust placed in raw packet claims and forcing traffic to align with routing reality. They also complement DNS hardening by preventing abuse of open resolvers and misrouted response paths.
The most common misapplication is treating it as a one-time perimeter setting, which occurs when organisations only configure edge firewalls but leave internal segments and cloud egress paths unfiltered.
Examples and Use Cases
Implementing ingress and egress filtering rigorously often introduces routing and troubleshooting complexity, requiring organisations to weigh stronger spoofing resistance against operational overhead and false-block risk.
- A DNS resolver blocks outbound packets with forged internal source addresses so an attacker cannot redirect amplified replies toward a victim.
- An internet-facing subnet enforces ingress filtering to reject packets claiming to come from private RFC 1918 ranges or other invalid sources.
- A cloud workload firewall applies egress filtering to service accounts that should only communicate through approved resolvers and APIs, reducing blast radius if a credential is abused.
- Network teams align packet filtering with NHI governance after reviewing exposure patterns described in the Ultimate Guide to NHIs, then map those controls to NIST Cybersecurity Framework 2.0 requirements for protective technologies.
- During incident response, a security team traces unexpected outbound traffic from a compromised API host and uses egress filtering to stop source spoofing while preserving legitimate service-to-service routes.
In DNS environments, these controls are especially useful when traffic crosses trust boundaries such as branch offices, partner links, or cloud-native overlays where packet origin is otherwise easy to falsify.
Why It Matters in NHI Security
Ingress and egress filtering matter because NHI compromise is often amplified by network paths that accept packets at face value. If a service account, API key, or automation host is abused, spoofed traffic can help an attacker obscure attribution, widen a reflection attack, or move malformed responses through infrastructure that should have rejected them. The control is therefore both a network hygiene measure and an NHI risk reducer. NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and only 5.7% of organisations have full visibility into their service accounts, underscoring how quickly hidden machine identities can become attack conduits when packet controls are weak. That finding is detailed in Ultimate Guide to NHIs.
For governance teams, filtering also supports Zero Trust by ensuring network trust is earned through policy and routing controls rather than assumed from location alone. It is most valuable when paired with least privilege, segmentation, and DNS monitoring, because spoofing protections alone do not stop misuse of valid credentials or misconfigured resolvers.
Organisations typically encounter the operational importance of ingress and egress filtering only after a spoofed-source incident or reflected DDoS event, at which point the control becomes unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.PT-4 | Protective technology guidance supports filtering spoofed traffic at boundaries. |
| NIST Zero Trust (SP 800-207) | Zero Trust minimizes implicit network trust and aligns with source validation. | |
| OWASP Non-Human Identity Top 10 | NHI-08 | NHI abuse often uses spoofed or misrouted traffic to hide compromised machine identities. |
Pair filtering with NHI monitoring to stop compromised identities from emitting deceptive traffic.
