Port 264: BGMP — The Ghost Protocol and the Firewall Leak

Port 264 carries two stories that never should have intersected. One is about a protocol designed with careful ambition that died before it lived. The other is about a security service that accidentally told attackers exactly what they wanted to know.

The Official Assignment: Border Gateway Multicast Protocol

Port 264 (both TCP and UDP) is officially registered to BGMP (Border Gateway Multicast Protocol)¹, a protocol specified in RFC 3913 by Dave Thaler of Microsoft in September 2004.²

BGMP was designed to solve inter-domain multicast routing—the problem of efficiently distributing multicast traffic (like live video streams or conferencing data) across multiple autonomous systems on the Internet. The protocol built shared trees for active multicast groups and supported both source-specific and any-source multicast.³

Here's what happened: BGMP never deployed. Not once. RFC 5110 documents the harsh truth: "BGMP did not get sufficient support within the service provider community to get adopted and moved forward in the IETF standards process, with no reported production implementations and no production deployments."⁴ The protocol was eventually reclassified to Historic status—the IETF's way of saying "this didn't work out."

Port 264 was reserved for a protocol that never ran anywhere.

The Actual Use: Check Point's Information Disclosure

While BGMP gathered dust, port 264 TCP found actual use in Check Point Firewall-1 products. Starting with SecuRemote build 4100, Check Point used this port for the Topology service—allowing VPN clients to fetch network topology information and encryption keys from the firewall management console.⁵

The problem: This service responded to unauthenticated queries. Anyone could connect to port 264 on a Check Point firewall and retrieve the firewall's hostname and the SmartCenter management station's name.⁶

For attackers, this was reconnaissance gold. Knowing you're facing a Check Point firewall changes your attack strategy. You know what exploits to try. You know what vulnerabilities to probe. One simple connection to port 264 answered questions that should have required significant effort to discover.

Security researchers were blunt about the risk: "You should not let this information leak out."⁷

The Security Impact

The port 264 information disclosure created several problems:

Reconnaissance made trivial: Attackers could identify Check Point firewalls instantly, focusing their attacks or changing strategies based on confirmed knowledge rather than guesses.

Enumeration of infrastructure: Hostnames and management station names often follow predictable patterns, revealing organizational structure and potentially other targets.

DoS vulnerability: The service was also implicated in denial of service attacks, though the information disclosure itself was the primary concern.⁸

Trust boundary violation: A firewall—the device meant to protect your network perimeter—was announcing its own identity to anyone who connected.

Mitigation

The fix was straightforward: uncheck "Accept Remote Access Control Connections" in the Check Point configuration if you don't require remote VPN access. After disabling this feature, port 264 stops responding to external queries.⁹

Modern Check Point deployments should have this addressed, but legacy systems and default configurations potentially left thousands of firewalls announcing themselves to the Internet for years.

The Double Irony

Port 264 is a study in unintended consequences. IANA assigned it to a protocol that the networking community rejected before it ever ran. Instead, a firewall vendor used the port for a legitimate feature that accidentally became an information disclosure vulnerability.

The protocol designed for careful, authenticated multicast routing never happened. The service that actually ran on the port leaked information to unauthenticated connections.

What Runs on Port 264 Today

Officially: BGMP, a protocol with zero production deployments

In practice: Potentially vulnerable Check Point firewall topology services on legacy systems

For most networks: Nothing—the port sits unused, reserved for a protocol that never lived and occasionally haunted by a security service that said too much

Check What's Listening

To see if anything is listening on port 264 on your system:

# On Linux/Mac:
sudo lsof -i :264
sudo netstat -tulpn | grep :264

# On Windows:
netstat -ano | findstr :264

If you find Check Point services on port 264, verify your configuration requires remote VPN topology fetching. If not, disable the feature.

Related Ports

• Port 259: ESRO (Efficient Short Remote Operations)—another obscure protocol in the well-known range
• Port 18231: Also associated with Check Point vulnerability scans related to the same CVE-2000-1201¹⁰
• Port 500: IKE (Internet Key Exchange)—the standard port for VPN key negotiation

Why Port 264 Matters

Port 264 tells two important stories about how the Internet actually works versus how we plan for it to work.

First: Protocol specifications don't guarantee adoption. BGMP had an RFC, had working group support, had careful design—and completely failed to deploy. The IANA registry is full of ports reserved for protocols that never ran anywhere. Port 264 is one of thousands of tombstones for good ideas that didn't survive contact with reality.

Second: Unassigned or unused ports don't stay empty. When BGMP failed to materialize, Check Point filled the vacuum with their own service. They had a legitimate need, they had an available port number, and they used it. The fact that the service had a security flaw is a separate issue from the port reuse itself.

The Internet's port system assumes careful central planning through IANA, but the reality is messier. Protocols fail. Vendors repurpose. Security vulnerabilities hide in legitimate features. Port 264 is where all of that happened at once.