264
Summary
- // if you see it open
- Pre-authentication information disclosure: a crafted request to 264/tcp returns the firewall hostname and management (SmartCenter) host name. Tooling: Metasploit auxiliary/gather/checkpoint_hostname (disclosed 2011-12-14); original OSI Security 'SecuRemote Topology Service Hostname Disclosure' advisory (Rapid7 DB). Check Point (sk69360) calls the info public; practical risk is fingerprinting/management-host naming for targeting (Shodan). Mitigation: uncheck 'Accept Remote Access Control Connections' or restrict FW1_topo source ranges. DoS CVE-2000-1201: packet flood to 264 → high CPU (sk132712). Do NOT conflate with CVE-2024-24919 (a 443/HTTPS-portal path-traversal info-disclosure in the Remote Access/Mobile Access blades, exploited from ~April 2024, CISA KEV).
- // analyst note
- An open 264/tcp is far more likely a Check Point firewall running SecuRemote than a (essentially nonexistent) BGMP speaker. Treat as fingerprinting/topology-disclosure recon and a pivot signal to enumerate the Check Point control plane.
About port 264/tcp.
Port 264/tcp is a registered-vs-de-facto split, and the de-facto side is what matters operationally. IANA registers it as bgmp with the description "BGMP," assignee Dave Thaler, and a blank reference field (dual-registered on TCP and UDP). The registered protocol, BGMP (Border Gateway Multicast Protocol), is defined in RFC 3913 (D. Thaler, Microsoft, September 2004, Informational) as an inter-domain multicast routing protocol — the multicast analog of BGP — that builds shared trees for active multicast groups, natively supports source-specific multicast, and for any-source multicast associates each group with a single root domain; RFC 3913 specifies that BGMP uses TCP port 264, distinct from BGP's port, for protocol independence. BGMP was effectively never deployed in production: RFC 5110 records that it gained insufficient support in the service-provider community, with no reported production implementations or deployments, and it was reclassified to Historic; there are no published BGMP CVEs. What is actually seen on TCP 264 in the wild is the Check Point FW-1 / SecuRemote topology service. Check Point's own documentation (sk52421) describes TCP 264 as FW1_topo, used for SecuRemote/SecureClient topology download from the Security Gateway, and it is enabled by the "Accept Remote Access Control Connections" implied rule, so it answers even under otherwise-restrictive policy; Nmap routinely fingerprints Check Point gateways via an open 264. The IANA reference field is blank. The security headline is a long-running pre-authentication information disclosure: a crafted request to 264/tcp returns the firewall's hostname and the management (SmartCenter) host name, and tooling is mature — Metasploit's auxiliary/gather/checkpoint_hostname (disclosed 2011-12-14) sends a pre-auth query to obtain the firewall and management-station names, and the original OSI Security "SecuRemote Topology Service Hostname Disclosure" advisory is mirrored in Rapid7's database. Check Point's official position (sk69360) is that the disclosed information is public, so the practical risk is firewall fingerprinting and management-host naming that aids targeting (readily surfaced via Shodan); mitigation is to uncheck "Accept Remote Access Control Connections" in Global Properties or restrict the FW1_topo source ranges. There is also a denial-of-service issue, CVE-2000-1201, in which a flood of packets to port 264 drives high CPU on FireWall-1 (referenced in Check Point sk132712). A separate, much newer flaw — CVE-2024-24919 (CVSS 8.6, exploited in the wild from ~April 2024, CISA KEV) — is an HTTPS-portal (443) path-traversal information disclosure in the Remote Access/Mobile Access blades and must not be conflated with the 264 topology service, though a 264 hit fingerprinting a Check Point gateway is a good reason to check that whole VPN/management surface. For an analyst, an open 264/tcp is far more likely a Check Point firewall running SecuRemote than a (essentially nonexistent) BGMP speaker; treat it as a reconnaissance, fingerprinting, and topology-disclosure consideration and as a pivot signal to enumerate the Check Point control plane.
- IANA assignment
bgmp— "BGMP"; reference (blank — no RFC cited in IANA registry); assignee Dave Thaler; dual-registered 264/tcp + 264/udp [IANA-assigned] — IANA Service Name and Transport Protocol Port Number Registry- Range class
- well-known (0–1023)
- Prevalence
- nmap-services open-frequency ~0.001029 (highest in this batch, driven by Check Point) [Well-established] — nmap-services file
- Related ports
- 179 (BGP, the unicast analog); Check Point cluster 256–259, 18190 (CPMI), 18210/18211, 18231, 18264, 500 (IKE for VPN-1)
De-facto use
Check Point FW-1 / SecuRemote topology service (FW1_topo) — NOT BGMP
Primary use (registered)
inter-domain multicast routing (BGMP, RFC 3913); never deployed, Historic per RFC 5110
Other/unofficial uses
Check Point SecuRemote/SecureClient topology download
Security implications
pre-auth hostname/topology disclosure (Metasploit checkpoint_hostname, disclosed 2011-12-14; OSI Security advisory; Check Point calls it public per sk69360); DoS CVE-2000-1201 (packet flood → high CPU, sk132712); do NOT conflate with CVE-2024-24919 (443 path-traversal, 2024)
Typically seen on
Check Point firewalls/security gateways
- Analyst note
- An open 264/tcp is far more likely a Check Point firewall running SecuRemote than a (essentially nonexistent) BGMP speaker. Treat as fingerprinting/topology-disclosure recon and a pivot signal to enumerate the Check Point control plane.
About port 264/udp.
Port 264/udp is registered with IANA as bgmp, described simply as "BGMP," with Dave Thaler listed as both assignee and contact; the registry's Reference, Registration Date, and Modification Date columns are all blank. The companion entry at 264/tcp carries an identical registration (same service name, description, assignee, and contact), so bgmp is a dual TCP/UDP assignment rather than a UDP-only one. BGMP itself — Border Gateway Multicast Protocol — is documented in RFC 3913, an Informational RFC published in September 2004 that specifies it as an inter-domain multicast routing protocol, conceptually BGP's multicast counterpart: border routers belonging to different multicast domains use it to exchange reachability and root/rendezvous-point information for shared multicast distribution trees, letting multicast routing scale across autonomous system boundaries the way BGP does for unicast. Despite the specification, BGMP never achieved meaningful real-world deployment; no vendor documentation (Cisco, Juniper, or otherwise) was found confirming a shipping production implementation, and the secondary sources available describe it as having been effectively bypassed by alternative inter-domain multicast approaches before it saw adoption. Given that apparent near-absence of deployment, a host answering on UDP/264 today is more plausibly generic UDP background noise, a scan artifact, or backscatter than a genuine BGMP listener — though no port-264-specific scanning signature has been documented in reputable sources to confirm that reading either way, so it is offered as a reasoned inference rather than an established fact.
- IANA assignment
bgmp— "BGMP"; Reference/Registration Date/Modification Date all blank; assignee and contact[Dave_Thaler]; dual-registered 264/tcp + 264/udp with identical fields [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry line 592 (264/tcp: line 591); cross-checked live at IANA's registry page- Range class
- well-known (0–1023) [Confirmed]
- IANA reference field
- blank in the registry itself; RFC 3913 documents the protocol but is not cited in IANA's own Reference column for this port entry, so it is reported here as related documentation rather than backfilled into that field [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry
- Assignment/registration date
- Unknown — IANA's registry exposes no registration date for this entry and none is fabricated [Unknown]
- Related ports
- 179/tcp (BGP, the unicast routing analog); 639/tcp (MSDP, one of the alternative inter-domain multicast approaches that saw wider adoption instead of BGMP)
Primary use
Border Gateway Multicast Protocol (BGMP), an inter-domain multicast routing protocol specified in RFC 3913 (Informational, September 2004) — the multicast analog to BGP, exchanging multicast reachability/root information between multicast-domain border routers
- Real-world deployment
- Likely none of consequence — no vendor documentation of a shipping BGMP implementation was found; secondary sources describe BGMP as never reaching meaningful production deployment [Likely] — https://en.wikipedia.org/wiki/Border_Gateway_Multicast_Protocol, https://handwiki.org/wiki/Border_Gateway_Multicast_Protocol
- Known CVEs
- none found; sourced from a single low-authority vendor blog, not independently cross-checked against NVD directly [Likely] — https://www.pentestpad.com/port-exploit/port-264-bgmp-border-gateway-multicast-protocol
- Security/exposure notes
- given the apparent lack of real deployment, unsolicited UDP/264 traffic is more plausibly scan noise or backscatter than genuine BGMP exposure; no port-264-specific scanning signature is documented in reputable sources, so this is an inference rather than a sourced fact [Unknown]
Service assignments.
| Name | Protocol | Description | Open frequency |
|---|---|---|---|
| bgmp | TCP | — | 0.10% |
| fw1-or-bgmp | UDP | FW1 secureremote alternate | 0.05% |
Service assignments from the IANA Service Name and Transport Protocol Port Number Registry, with open-frequency data from nmap-services.