Port 179 – BGP (Border Gateway Protocol)

Port 179 is the default TCP port for BGP (Border Gateway Protocol), the routing protocol that stitches the internet’s tens of thousands of autonomous systems (ASes) together. Two routers open a TCP connection on port 179 to become BGP peers, then exchange the network prefixes each side can reach so traffic can find a path across administrative boundaries. BGP is defined in RFC 4271 and runs over TCP 179 for reliable, ordered delivery of routing updates — which is also why it inherits every TCP-session weakness, from RST injection to sequence-number guessing, and why the protocol’s biggest risks (route hijacking and leaks) live at the design level rather than in any single bug.

Why It’s Open

BGP only runs where autonomous systems meet, so port 179 shows up on internet-facing and core infrastructure rather than ordinary hosts: ISP edge and core routers, data-center and cloud gateways, internet exchange points (IXPs), and large multi-homed enterprises that run their own AS. It has also moved inside the data center — Kubernetes networking layers like Calico and Cilium speak BGP on 179 to advertise pod and service routes to the fabric.

The key thing about port 179 is that peers are explicitly configured: each router statically lists its neighbor’s IP address and AS number, so a well-run BGP speaker only accepts a session from those known addresses. That means 179 should almost never be reachable by the whole internet. Seeing it open on a host you don’t expect — or unsolicited BGP SYNs piling up in a firewall log — is itself worth investigating. The same routers usually expose a management plane one scan away: SSH on port 22 or legacy Telnet on port 23 for the CLI, and SNMP on port 161 for monitoring — including reading live BGP peer state.

Common Risks

• BGP hijacking / prefix hijacking. The headline threat. Because classic BGP has no built-in origin validation, a router accepts whatever prefixes a peer announces. An AS that announces address space it doesn’t own — especially a more-specific prefix — pulls the victim’s traffic toward itself, enabling interception, blackholing, or phishing.
• Route leaks. A misconfigured or compromised peer re-advertises routes it should have kept to itself (for example, leaking one provider’s full table to another provider). The result is global detours and outages, even without malicious intent.
• TCP session reset and hijacking. Long-lived BGP sessions on TCP 179 are targets for RST injection and TCP sequence-number guessing (CVE-2004-0230). Resetting a session tears down every route it carried (a flap), and a successfully hijacked session can inject arbitrary routes. This is exactly why TCP-MD5 (RFC 2385), the stronger TCP-AO (RFC 5925), and GTSM/TTL-security (RFC 5082) exist.
• Implementation parse bugs. A malformed BGP OPEN or UPDATE message can crash the routing daemon (bgpd in FRRouting and Quagga have both been hit), a denial of service reachable by any configured peer.
• Exposure beyond configured peers. When 179 is open to more than the intended neighbors, it invites unsolicited connection floods, reconnaissance of your peering topology, and attempts to brute a session with a spoofed neighbor address.

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 179 <target>

There is no dedicated BGP NSE script in Nmap — version detection and a banner grab are what you get on the port itself. The asn-query and targets-asn scripts exist but query whois/ASN data, not the BGP speaker.

Confirm the port answers

nc -nv <target> 179

A properly configured speaker won’t complete a session without a matching neighbor config, but a response confirms something is listening on 179.

Craft and fuzz BGP messages with Scapy

python3
>>> from scapy.all import *
>>> load_contrib("bgp")
>>> # Build a BGP OPEN to probe the handshake / fuzz the parser
>>> hdr = BGPHeader(type=1)
>>> open_msg = BGPOpen(my_as=64512, bgp_id="10.0.0.1", hold_time=180)
>>> send(IP(dst="<target>")/TCP(dport=179)/hdr/open_msg)

Stand up a test speaker with ExaBGP

# ExaBGP is a Python BGP route injector — use it to attempt a session
# or announce a test prefix in a lab
exabgp exabgp.conf
# neighbor <target> local-as 64512 peer-as 65001; announce route 203.0.113.0/24 next-hop self

Read BGP peer state over SNMP (BGP4-MIB)

# If SNMP is reachable on the router, the BGP4-MIB exposes peer state
snmpwalk -v2c -c public <router> 1.3.6.1.2.1.15

There is no dedicated Metasploit BGP module — session attacks rely on getting on-path (ARP spoofing with Ettercap/dsniff), TCP-hijacking the session, then injecting Scapy-crafted UPDATEs; don’t expect a one-command MSF exploit. On the routing side, public looking glasses and route-collector projects (RIPE RIS, RouteViews, and bgpdump on their MRT archives) let you see exactly what an AS announces without touching the target.

Log every open 179, every accepted session attempt, and every prefix you see announced so it lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

BGP’s most damaging problems — prefix hijacking and route leaks — are design-level and have no CVE; they’re addressed by RPKI, filtering, and the mitigations below. The tracked CVEs are the TCP-layer and implementation bugs, and most require the attacker to be a configured or on-path BGP peer rather than an anonymous internet host:

• CVE-2004-0230 — The classic TCP RST / sequence-number attack (“Slipping in the Window”). Because BGP endpoints are stable and well-known and the session uses large windows, an off-path attacker can guess a valid sequence number and inject a RST to reset the peering, dropping every route it carried. CVSS 5.0. It is the direct reason production BGP moved to TCP-MD5, and later TCP-AO and GTSM. Archived on Exploit-DB.
• CVE-2018-5379 — A double-free in the Quagga BGP daemon (bgpd) before 1.2.3 when processing UPDATE messages containing cluster-list and/or unknown attributes. A malicious or compromised peer can crash or potentially execute code on the daemon. NVD rates it CVSS 9.8 (CERT/CC rates the practical impact 7.5).
• CVE-2022-40302 — An out-of-bounds read in FRRouting bgpd through 8.4. A BGP OPEN message with an option of type 0xff (the RFC 9072 extended length) trips an assertion failure and daemon restart or an OOB read — a DoS from a configured peer. CVSS 6.5.
• CVE-2022-43681 — Another out-of-bounds read in FRRouting bgpd through 8.4: a malformed BGP OPEN that ends right at the option-length octet makes the code read past the packet and abort (SIGABRT), restarting the daemon. CVSS 6.5.
• CVE-2023-38802 — A crafted BGP UPDATE with a corrupted attribute 23 (Tunnel Encapsulation) crashes FRRouting (7.5.1 through 9.0) and Pica8 PICOS, a remotely triggered denial of service. CVSS 7.5.

Mitigation

• Authenticate the session. Enable TCP-MD5 signatures (RFC 2385) on every peering, or the stronger TCP-AO (RFC 5925) where both sides support it. This is the baseline defense against RST injection and session hijacking.
• Enforce GTSM / TTL-security (RFC 5082). Require an incoming TTL of 255 so only a directly adjacent peer can establish the session, shutting out remote, non-adjacent attackers.
• Filter prefixes and cap them. Apply strict inbound and outbound prefix lists and AS-path filters so a peer can only announce what it’s authorized to, and set a max-prefix limit so a leak or hijack trips a threshold instead of poisoning your table. Tools like bgpq4 generate these filters from IRR data.
• Validate route origins with RPKI. Publish ROAs for your prefixes and drop RPKI-invalid routes (ROV). Run a validator such as Routinator (RPKI-to-router) so your routers reject announcements from an unauthorized origin AS.
• Follow MANRS. The Mutually Agreed Norms for Routing Security bundle the above — filtering, anti-spoofing (BCP 38), coordination, and global validation — into an operational baseline.
• Lock down port 179 with infrastructure ACLs. Permit TCP 179 only from your configured neighbor IPs and block it at the edge otherwise. Port 179 should never be open to the general internet.
• Patch the routing daemon. Keep FRRouting, Quagga, BIRD, and vendor OSes (Cisco IOS XR, Junos) current to close the malformed-message parse bugs that let a peer crash bgpd.

Real-World Example

In February 2008, Pakistan Telecom (AS17557) tried to block YouTube domestically by announcing a more-specific route for one of YouTube’s prefixes (208.65.153.0/24). The announcement leaked to its upstream provider and propagated across the internet; because it was more specific than YouTube’s own advertisement, routers worldwide preferred it and sent YouTube’s traffic into a Pakistani black hole for roughly two hours. No exploit and no malware — just a single unfiltered BGP announcement that the rest of the internet trusted.

The same trust is abused for profit. In April 2018, attackers hijacked Amazon Route 53’s authoritative-DNS prefixes by injecting a BGP route that propagated through a US transit provider, redirecting DNS queries to attacker-controlled servers. Those servers resolved MyEtherWallet.com to a phishing clone hosted on Russian infrastructure, and users who ignored the TLS warning lost roughly $150,000 in Ethereum. Both incidents are textbook arguments for prefix filtering and RPKI origin validation — the DNS layer (port 53) was only reachable to hijack because the routing layer accepted a bogus origin.

FAQ

What is port 179 used for?

Port 179 is the TCP port BGP (Border Gateway Protocol) uses to establish peering sessions between routers. Two BGP speakers open a TCP connection on 179 and exchange reachability information — the network prefixes each can deliver — so traffic can be routed between different autonomous systems across the internet.

What port does BGP use, and is it TCP or UDP?

BGP uses TCP port 179 — the BGP port number is 179, and it is TCP only. There is no UDP version of BGP; RFC 4271 specifies TCP so that routing updates get reliable, ordered, error-checked delivery. That reliance on a long-lived TCP session is also why TCP-layer attacks like RST injection matter to BGP.

Why is port 179 open, or why am I seeing BGP connection attempts?

If a device is a router that peers with another AS, 179 being open to that specific neighbor is expected. If you see unsolicited BGP SYNs to port 179 from random addresses — a common sight in firewall logs — it’s usually internet background scanning, a misconfigured or leftover neighbor statement, or someone probing for exposed BGP. A speaker should only accept sessions from its configured peers, so investigate any 179 that answers the wider internet.

Is port 179 dangerous?

The port itself is a normal routing service, but the protocol behind it carries outsized risk: an accepted-but-unfiltered BGP session can be used to hijack traffic or leak routes far beyond the local network, and an unauthenticated session can be reset or hijacked at the TCP layer. Restricted to configured peers with authentication, filtering, and RPKI, the risk is manageable; open to the internet without those controls, it’s a serious exposure.

How do I secure or close port 179?

Authenticate every peering with TCP-MD5 or TCP-AO, enforce GTSM/TTL-security, apply strict prefix filters plus a max-prefix limit, and validate origins with RPKI (ROV). Restrict TCP 179 with an infrastructure ACL so only your configured neighbors can reach it, and keep the routing daemon patched. If a device shouldn’t be running BGP at all, disable the daemon and confirm the port is closed with a rescan.

TL;DR

• Service: BGP (Border Gateway Protocol) — inter-AS routing between peers
• Default port: 179/TCP (TCP only; defined in RFC 4271)
• Biggest risk: prefix hijacking and route leaks (design-level, no CVE), plus TCP-session reset/hijack (CVE-2004-0230) and bgpd parse-bug DoS
• Mitigation: authenticate with TCP-MD5/TCP-AO, GTSM/TTL-security, prefix filters + max-prefix, RPKI origin validation, and restrict 179 to configured peers with an ACL
• Not to be confused with BGMP on port 264, the separate multicast inter-AS routing protocol