MSS: (DisableIPSourceRouting) IP source routing protection level (protect against packet spoofing)

MSS: (DisableIPSourceRouting) IP source routing protection level (protect against packet spoofing)

4 Minutes Read Updated on May 21, 2025

Optimally configuring “DisableIPSourceRouting” parameter enhances security by mitigating the risk of denial-of-service (DOS) attacks through packet spoofing. In such attacks, the goal is to inundate the target with high volumes of traffic, and using spoofed IP addresses makes it challenging to filter and identify the true source of the attack.

Server hardening can be arduous. CSH by CalCom automates the process, learning your network to eliminate the need for testing. Implement your policy hassle-free with zero production outages. Want more details? Click HERE.

request demo

This blog post will cover:

  1. What is IP Source Routing Protection Level policy?
  2. The potential vulnerability in this setting
  3.  Countermeasures for mitigating this vulnerability
  4. The potential impact of the configuration change
  5. CalCom’s recommended value
  6. How to change the configuration

POLICY DESCRIPTION

The registry value entry DisableIPSourceRouting was added to the template file in the HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTcpipParameters registry key. The entry appears as MSS: (DisableIPSourceRouting) IP source routing protection level (protects against packet spoofing) in the SCE.

IP source routing is a mechanism that allows the sender to determine the IP route that a datagram should take through the network. Microsoft recommends configuring this setting to Not Defined for enterprise environments and to Highest Protection for high-security environments to completely disable source routing.

POTENTIAL VULNERABILITY

An attacker could use source routed packets to obscure their identity and location. Source routing allows a computer that sends a packet to specify the route that the packet takes.

BLIND SPOOFING ATTACKS – PACKET SPOOFING:

Sometimes attackers do not actually need a connection with a server host; rather they just need to spoof a single packet, to do a certain thing. In this case, all an attacker needs to do is to inject a packet/datagram/segment, and set a fake source address. As you can probably see, this is quite a big flaw and security vulnerability in TCP/IP, as the TCP/IP suite makes absolutely no attempt at verifying that the supplied source address is actually the real one.

Say, for example, there is a game that allows you to play against somebody over the Internet, but instead of using the TCP protocol for transferring the data to each opponent, it uses UDP for extra speed. Imagine that the author of the game writes a little routine that made the play quit/submit the game if they send the string “LOSE” in the UDP datagram, and this option is accessed via a little menu on the game. All an attacker has to do to make his opponent lose the game is spoof a UDP datagram to appear as if it originated from your opponent, and inject the string “LOSE” into it.

Here is a basic diagram of what would be happening during one of these packet-spoofing attacks:

Host X: SRC (Host C), DATA (“LOSE”) -> Host S

…Host S closes the session, and Host C loses the game…

The datagram sent by Host X (the attacker) had a spoofed source address, pretending to be from Host C (the opponent). The game server receives the datagram, presumed it was from Host C, and consequently ended the game, leaving Host X as the winner.

This does not seem like a huge security flaw, but what if this was a login server we were attacking, which the author had written to automatically execute commands specified by the sender just by checking that the source address was right? Then the system would be at risk.

server hardening

COUNTERMEASURES

Configure the MSS: (DisableIPSourceRouting) IP source routing protection level (protects against packet spoofing) entry to a value of Highest protection, source routing is completely disabled.

The possible values for this registry entry are:

  • 0, 1, or 2. The default configuration is 1 (source-routed packets are not forwarded).

In the SCE UI, the following list of options appears:

  • No additional protection- source-routed packets are allowed.
  • Medium- source-routed packets ignored when IP forwarding is enabled.
  • Highest protection- source routing is completely disabled.
  • Not Defined.

POTENTIAL IMPACT

If you configure this value to 2, all incoming source routed packets will be dropped.

SEVERITY

Important.

CALCOM’S RECOMMENDED VALUE:

Highest protection, source routing is completely disabled (2)

OSPF protocol: Configuration, Features & Best Practices

HOW TO CONFIGURE DisableIPSourceRouting:

The policy referenced configures the following registry value:

Registry Hive: HKEY_LOCAL_MACHINE
Registry Path: SystemCurrentControlSetServicesTcpipParameters

Value Name: DisableIPSourceRouting

Value Type: REG_DWORD
Value: 2

Remediation

To establish the recommended configuration via GP, set the following UI path to Enabled: Highest protection, source routing is completely disabled:

Computer ConfigurationPoliciesAdministrative TemplatesMSS (Legacy)MSS:
(DisableIPSourceRouting) IP source routing protection level (protects against
packet spoofing)

Note: This Group Policy path does not exist by default. An additional Group Policy template (MSS-legacy.admx/adml) is required

Ben Balkin
Ben Balkin is a professional writer and blogger specializing in technology and innovation. As a contributor to the Calcom blog, Ben shares practical insights, useful tips, and engaging articles designed to simplify complex processes and make advanced technological solutions accessible to everyone. His writing style is clear, insightful, and inspiring, reflecting his strong belief in technology's power to enhance quality of life and empower businesses.

Related Articles

TrustedInstaller – with great power comes great responsibility

TrustedInstaller – with great power comes great responsibility

September 3, 2024

What is Trustedinstaller TrustedInstaller is a Windows system account with special high-level permissions allowing it…

Kerberos v5 Authentication vs v4

Kerberos v5 Authentication vs v4

June 1, 2024

Kerberos Authentication Explained Kerberos stands as the default authentication protocol facilitating secure service requests between…

What is FFIEC Compliance?

What is FFIEC Compliance?

November 22, 2023

As financial institutions navigate the ever-evolving challenges of cybersecurity, understanding and implementing the Federal Financial…

Ready to simplify compliance?

See automated compliance in action—book your demo today!

Share this article