PCI DSS 1.4.3: Anti-spoofing measures are implemented to detect and block forged source IP addresses

PCI DSS v4.0.1 control 1.4.3: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 1.4.

Requirement 1: Install and Maintain Network Security Controls › Section 1.4

Anti-spoofing measures are implemented to detect and block forged source IP addresses from entering the trusted network.

Summary

Detect and block packets arriving with a forged internal source address.

What the assessor will examine

These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.

Procedure
1.4.3 Examine vendor documentation and configurations for NSCs to verify that anti-spoofing measures are implemented to detect and block forged source IP addresses from entering the trusted network.

Frequently assumed to be covered by the general inbound rules, and it is not. Your rules make decisions based on source address, so a packet arriving from outside carrying an internal source address may match rules written for internal traffic and pass. Anti-spoofing is what makes address-based filtering trustworthy in the first place, which is why it is a separate control rather than a refinement of 1.4.2. In practice this is ingress filtering at the boundary: dropping inbound packets whose source belongs to your internal ranges, and dropping outbound packets whose source does not. Many devices implement it as a reverse-path check that is available and off by default. The procedure examines vendor documentation and configurations, so it is answered by a setting you can point at.

What to prepare

  • The internal address ranges that should never appear as an inbound source.
  • NSC configuration showing the anti-spoofing mechanism enabled.
  • Vendor documentation for the mechanism, which the procedure examines alongside the configuration.
  • Coverage across every boundary, not just the primary internet edge.

How to implement it

1. Turn on reverse-path filtering where the platform offers it. It is usually a single setting and it implements the control more completely than hand-written rules.

2. Filter in both directions. Blocking forged inbound protects you; blocking forged outbound stops your network being used to attack someone else, and it catches a compromised host.

3. Cover every ingress point. Partner links, VPN concentrators and cloud gateways are all boundaries where a forged source can arrive.

4. Verify rather than assume. The mechanism is commonly present and disabled, so the check is a configuration read rather than a design discussion.

Where this commonly fails

  • Assumed to be covered by the inbound ruleset, which decides on the source address the attacker is forging.
  • The mechanism available and left at its default of off.
  • Applied at the internet edge only, leaving partner and VPN boundaries open.
  • Outbound spoofing unfiltered, so a compromised internal host can forge freely.

Others in section 1.4:

Control What it requires
1.4.1 NSCs are implemented between trusted and untrusted networks
1.4.2 Inbound traffic from untrusted networks to trusted networks is restricted…
1.4.4 System components that store cardholder data are not directly accessible from untrusted networks
1.4.5 The disclosure of internal IP addresses and routing information is limited to only authorized…

1.4.2 · All controls · 1.4.4

Source

The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.

The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.