BGP port 179 accessible through public VRF's vlan interfejs ip address


After configuring VRF to route public prefixes into the fabric, I scanned ip address of default gateway in this public prefix, which is leaf's VLAN interface in VRF "public". And I found out few ports being accessible: 10050, 22, 179. First two: easy part, just disable zabbix-agent and ssh services in default VRF and run them in mgmt VRF. It should be done anyway.

But what about FRR, which - I guess - is responsible for BGP's port 179.
Another check confirmed that port 179 seem to be open in default VRF (scanned VLAN default gateway ip address from server).

Is that by design? I find it a security issue. How to solve this?

3 replies

Userlevel 4
The behavior you describe is expected. When attempting in my environment to connect to the gateway (a leaf running BGP) via telnet you can see the connection is instantly closed by FRR who does not have a BGP session active on this port.

cumulus@server03:~$ telnet 10.0.30.1 179
Trying 10.0.30.1...
Connected to 10.0.30.1.
Escape character is '^]'.
Connection closed by foreign host.
cumulus@server03:~$

There is a rate limiter for the traffic in place as part of the default control plane rules seen here:
cumulus@leaf01:~$ cat /etc/cumulus/acl/policy.d/00control_plane.rules | grep bgp
-A $INGRESS_CHAIN --in-interface $INGRESS_INTF -p tcp --dport bgp -j SETCLASS --class 7
-A $INGRESS_CHAIN -p tcp --dport bgp -j POLICE --set-mode pkt --set-rate 2000 --set-burst 2000
-A $INGRESS_CHAIN --in-interface $INGRESS_INTF -p tcp --sport bgp -j SETCLASS --class 7
-A $INGRESS_CHAIN -p tcp --sport bgp -j POLICE --set-mode pkt --set-rate 2000 --set-burst 2000
-A $INGRESS_CHAIN --in-interface $INGRESS_INTF -p tcp --dport bgp -j POLICE --set-mode pkt --set-rate 2000 --set-burst 2000 --set-class 7
-A $INGRESS_CHAIN --in-interface $INGRESS_INTF -p tcp --sport bgp -j POLICE --set-mode pkt --set-rate 2000 --set-burst 2000 --set-class 7

You can build an ACL to block traffic coming in on port 179 and apply that to host-facing ports which would look something like this.

cumulus@leaf01:~$ cat /etc/cumulus/acl/policy.d/30bgp_host_protection.rules
-t filter -A INPUT --in-interface swp1 -p tcp --dport bgp -j DROP
-t filter -A INPUT --in-interface swp2 -p tcp --dport bgp -j DROP
-t filter -A INPUT --in-interface swp3 -p tcp --dport bgp -j DROP
Thanks for Your answer, Eric. I focused on building fabrics (L2 w/ MLAG, BGP unnumbered, EVPN) so I didn't play with ACLs yet.
I still think what You wrote is a workaround, not a solution. BGP should not listen on VLAN interfaces, unless configured to do so? Telnet connection is being closed instantly, but what's gonna happen when proper BGP client tries to connect? Rate limiter does not solve this.
Rather then having ACL entry fro every host-facing port I'd like to have one ACl entry for VLAN interface. If my leaves and spines are running BGP unnumbered, and spine is to peer (BGP) with upstream router, where can I place the ACL filtering BGP port?

As I admitted I just started with ACLs, so maybe I'll find answers in the documentation.
Userlevel 4
Jakub Bitenc wrote:

Thanks for Your answer, Eric. I focused on building fabrics (L2 w/ MLAG, BGP unnumbered, EVPN) so...

I tend to agree with you but there's a bit more to it. Ultimately it comes down to how FRR is coded to build a socket, whether or not that socket binds to a specific interface or not. In many cases it would not be desireable for BGP to bind to a specific interface... think of ebgp multihop etc where the packet could come in on one of many interfaces... also for iBGP. For the specific case of point-to-point directly connected eBGP the socket could be made to bind to a specific interface but that would not protect the box if another BGP session was created using any of the other BGP connectivity options mentioned above. I'm told this is standard behavior for other vendors like Cisco etc but I've not taken the time specifically to test.

Reply