Port 264 – BGMP (Border Gateway Multicast Protocol)

Port 264 has a split identity, and the gap between them matters. By IANA registration the port belongs to BGMP (Border Gateway Multicast Protocol), an inter-domain multicast routing protocol defined in RFC 3913 that was designed to build a single shared distribution tree per multicast group across autonomous-system boundaries. BGMP stayed experimental and was never meaningfully deployed — the internet settled on PIM-SM with MSDP for inter-domain multicast instead — so you will almost never meet a live BGMP speaker in the wild. In practice, an open TCP 264 almost always means a Check Point FireWall-1 / VPN-1 security gateway, not BGMP. Check Point uses 264 for the SecuRemote / SecureClient topology service (registered in /etc/services as FW1_topo): the pre-authentication request a remote-access VPN client makes to download the gateway’s network topology before the tunnel comes up. That service is what nmap, Shodan, and pentesters actually find on 264 — and it has a long-documented habit of answering questions it shouldn’t.

This page covers both but weights the Check Point reality, because that is what an open 264 means on a real engagement. Not to be confused with BGP on port 179: BGP is unicast inter-AS routing, while BGMP is the separate multicast protocol — same “border gateway” naming, different port, different job.

Why It’s Open

If 264 answers, you are almost certainly looking at a Check Point gateway, not a router doing multicast. FW1_topo is an implied-rule service that the gateway exposes so SecuRemote, SecureClient, and Endpoint Connect clients can fetch the topology of the network they’re about to VPN into. Because it’s part of the remote-access handshake, it frequently answers even when the rest of the security policy is tightly locked down — which makes a hit on 264 both a reliable fingerprint for Check Point and a strong hint that a remote-access VPN is configured on the box.

The genuine-BGMP case is the rare one: a lab, a research testbed, or an exotic legacy multicast deployment. For any internet-facing or enterprise host, treat an open 264 as Check Point until proven otherwise. The same gateway usually exposes its management and VPN plane a scan or two away — SSH on port 22 or legacy Telnet on port 23 for the CLI, SNMP on port 161 for monitoring, and IPsec IKE on port 500 for the VPN itself — so 264 is often the thread you pull to map the rest.

Common Risks

• Unauthenticated topology / hostname disclosure. The headline issue. A SecuRemote topology request to 264 is answered before authentication, and the reply carries the firewall object name and the SmartCenter/management station’s certificate CN. On older or loosely configured gateways it also returned internal network objects, the encryption domain, and interface addresses — a free map of the internal network for anyone who can reach the port.
• Internal interface IP leakage (CVE-2003-0757). On FireWall-1 4.0/4.1 before SP5, certain SecuRemote requests to TCP 256 or 264 leak the IP addresses of the gateway’s internal interfaces straight back in the reply — the classic fw1_getints finding.
• Denial of service (CVE-2000-1201). A flood of packets to port 264 drives FireWall-1 CPU to exhaustion, degrading or dropping traffic through the gateway.
• Target fingerprinting. Even when it discloses nothing sensitive, a hit on 264 immediately narrows the target to Check Point and signals that remote-access VPN is present — which directs the next moves toward IKE/VPN attacks on port 500 and the management ports.
• Multicast route manipulation (BGMP, theoretical). In the rare event you actually find BGMP, the protocol has no built-in authentication, so a peer could inject or manipulate inter-domain multicast state and disclose multicast topology — but this is a design-level concern on a protocol that essentially nobody runs.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and version

nmap -sV -p 264 <target>

There is no dedicated Check Point NSE script in Nmap for port 264 — version detection fingerprints the service (often shown as FW1_topo / Firewall-1) and confirms you’re dealing with Check Point rather than BGMP. That fingerprint alone is the first useful finding.

Pull the firewall and management name with Metasploit

msfconsole -q
use auxiliary/gather/checkpoint_hostname
set RHOSTS <target>
run

The checkpoint_hostname module sends the pre-authentication SecuRemote topology request and returns the Check Point Internal CA CN for the SmartCenter and the firewall host — the gateway and management station names, no credentials required.

Raw SecuRemote topology request with netcat

printf '\x51\x00\x00\x00\x00\x00\x00\x21\x00\x00\x00\x0bsecuremote\x00' \
  | nc -q 1 <target> 264 | grep -a CN | cut -c 2-

This is the same topology probe by hand: it speaks the SecuRemote request and greps the certificate details (CN and organization) out of the reply, confirming the Check Point identity from first principles.

Confirm the port answers

nc -nv <target> 264

A response confirms something is listening; pair it with the probes above to decide whether it’s FW1_topo or (rarely) an actual BGMP speaker.

Log every open 264, the gateway/management names, and any leaked interface addresses so they land in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

BGMP itself has no CVEs in the NVD — unsurprising for a protocol that was never deployed at scale. The tracked vulnerabilities on port 264 all belong to the Check Point FireWall-1 SecuRemote service that actually lives there:

• CVE-2003-0757 — Check Point FireWall-1 4.0 and 4.1 before SP5 lets remote attackers obtain the IP addresses of the gateway’s internal interfaces via certain SecuRemote requests to TCP 256 or 264, leaking the addresses in the reply packet. CVSS v2 5.0. This is the vulnerability behind the classic fw1_getints tool, archived on Exploit-DB (BID 8524).
• CVE-2000-1201 — Check Point FireWall-1 allows a remote attacker to cause a denial of service (high CPU) by flooding port 264. CVSS v2 5.0. Check Point references it in sk132712 alongside guidance for the 264/18231 listeners a vulnerability scan will flag.
• SecuRemote Topology Service hostname disclosure (no CVE). The pre-auth name disclosure has no CVE assigned — Rapid7 classes the returned data as “public” — but it’s a live, current-day technique, weaponised as Metasploit’s auxiliary/gather/checkpoint_hostname. It still returns the firewall and SmartCenter CNs on modern gateways, which is why it remains a standard recon step against any open 264.

Mitigation

• Restrict who can reach 264. The SecuRemote topology service should only be reachable by the networks that legitimately run the VPN client. Block TCP 264 from the general internet and from untrusted internal segments with a rule ahead of the implied-rule service.
• Require authenticated topology downloads. On modern Check Point gateways, require users to authenticate before the topology is served (Remote Access / Office Mode settings) so an anonymous request can’t map the internal network. Review the encryption domain so it doesn’t expose more than the client needs.
• Retire FireWall-1 4.x. Anything vulnerable to CVE-2003-0757 is far past end-of-life; upgrade to a supported version where the interface-address leak is fixed and topology handling is authenticated.
• Rate-limit and monitor 264. Guard against the CVE-2000-1201 flood with connection/rate limits, and alert on repeated topology requests — they’re reconnaissance, not normal client behaviour at volume.
• Lock down the rest of the plane. A gateway found on 264 usually exposes management and VPN services too — harden SSH (22), kill Telnet (23), secure SNMP (161), and review IKE on 500.
• If it’s genuinely BGMP, ask why. A real BGMP listener is almost certainly a leftover experiment; confirm it’s needed and disable it if not, since the protocol carries no authentication of its own.

Real-World Example

For years, an open TCP 264 was a gift on external penetration tests. A tester would scan a target’s perimeter, find 264 answering, and fire a single SecuRemote topology request — no credentials, no exploit chain. On FireWall-1 4.x the reply handed back the gateway’s internal interface addresses (the fw1_getints technique behind CVE-2003-0757), and on many installs it went further, returning the names of internal network objects and the VPN encryption domain. From one unauthenticated packet the tester learned the internal addressing plan, the naming convention, and the shape of the network behind the firewall — reconnaissance that would otherwise take a foothold to gather.

Check Point tightened the defaults over successive versions — modern gateways can require authentication before serving topology — but the softer disclosure never fully closed: the checkpoint_hostname request still returns the firewall and SmartCenter certificate names on current builds. It’s a textbook case of a convenience feature (let the VPN client pre-fetch topology) quietly doubling as an information-disclosure channel, and it’s exactly why a hit on 264 is worth more than “another open port.”

FAQ

What is port 264 used for?

Two things, depending on what’s actually listening. By IANA registration, port 264 belongs to BGMP (Border Gateway Multicast Protocol), an inter-domain multicast routing protocol from RFC 3913 that was never meaningfully deployed. In practice, an open TCP 264 is the Check Point FireWall-1 / VPN-1 SecuRemote topology service (FW1_topo), which VPN clients query to download the gateway’s network topology.

Why is port 264 open on my Check Point firewall?

Because SecuRemote / SecureClient / Endpoint Connect clients use it to fetch topology before establishing the VPN. It’s an implied-rule service, so the gateway answers it even under an otherwise strict policy. If you don’t run Check Point remote-access VPN, that port shouldn’t be exposed to untrusted networks — restrict it.

Is port 264 BGMP or Check Point?

Almost always Check Point. BGMP is the registered assignment but was experimental and effectively never deployed, so a live BGMP speaker is a rarity. Nmap, Shodan, and pentest scans that turn up 264 are finding the Check Point SecuRemote topology service in the overwhelming majority of cases. Fingerprint the service with nmap -sV to be sure.

Is port 264 dangerous?

The service is a normal part of Check Point remote access, but it’s a reconnaissance goldmine when exposed. It answers topology and name requests before authentication, disclosing the firewall and management station names and — on older or loose configs — internal interface addresses and network objects. That won’t hand over a shell, but it maps the internal network and names the next target, which is why testers chase it.

How do I secure or close port 264?

Restrict TCP 264 to the networks that legitimately run the VPN client, require authenticated topology downloads on modern gateways, upgrade off any FireWall-1 4.x affected by CVE-2003-0757, and rate-limit the port against flooding (CVE-2000-1201). If the host isn’t a Check Point remote-access gateway, block the port and rescan to confirm it’s closed.

TL;DR

• Service: Registered to BGMP (Border Gateway Multicast Protocol, RFC 3913) — but an open 264 is almost always Check Point FireWall-1 / VPN-1’s SecuRemote topology service (FW1_topo)
• Default port: 264/TCP (also UDP by registration; BGMP is historical/undeployed)
• Biggest risk: unauthenticated topology, hostname, and internal-interface disclosure (CVE-2003-0757), plus a DoS by flooding (CVE-2000-1201) — recon, not RCE
• Mitigation: restrict 264 to VPN clients, require authenticated topology downloads, retire FireWall-1 4.x, rate-limit and monitor
• Not to be confused with BGP on port 179, the separate unicast inter-AS routing protocol