bgp | IPNET - Part 2

Cisco IOS Software BGP 4-Byte AS Number Vulnerabilities

Recent versions of Cisco IOS Software support RFC4893 (“BGP Support for Four-octet AS Number Space”) and contain two remote denial of service (DoS) vulnerabilities when handling specific Border Gateway Protocol (BGP) updates.

These vulnerabilities affect only devices running Cisco IOS Software with support for four-octet AS number space (here after referred to as 4-byte AS number) and BGP routing configured.The device is vulnerable if it is running affected Cisco IOS version and has BGP configured, regardless of whether the device is configured with a 2 or 4 byte AS number under the router bgp configuration command

The first vulnerability could cause an affected device to reload when processing a BGP update that contains autonomous system (AS) path segments made up of more than one thousand autonomous systems.

The second vulnerability could cause an affected device to reload when the affected device processes a malformed BGP update that has been crafted to trigger the issue.

Cisco has released free software updates to address these vulnerabilities.

No workarounds are available for the first vulnerability.

A workaround is available for the second vulnerability. For the second vulnerability, configuring “bgp maxas-limit [value]” on the affected device does mitigate this vulnerability. Cisco is recommends using a conservative value of 100 to mitigate this vulnerability.

This advisory is posted at the following link: http://www.cisco.com/warp/public/707/cisco-sa-20090729-bgp.shtm

Cisco: 6 best practice security tips for BGP

As we all know, in today’s digital communication world, there is a very big possibility that your network is or was target for a malicious activity. BGP is one of the most targeted routing protocols when we are talking about network attacks.Why? This is quite simple. BGP is your connection to the exterior world (peer networks, Internet and everything which is outside your LAN/MAN), so it is somehow normal to be the main target of the conducted attacks. If in case of the WWW, DNS, E-mail services we can say that maybe an attack was not intentionally made (e.g. a user got infected with some trojan/malware/botnet tool that is attacking random destinations), in the case of BGP, you can be 90% sure that this is an intentionally conducted attack. The main scope of a BGP attack is to flood the network with false information (e.g. false network prefixes) in this way trying to direct interesting traffic to special destinations where this can be sniffed and decoded.

I will present here 6 tips that I’m using the most to protect BGP against malicious information. This is really easy to implement, if you have any basic idea about how to configure BGP protocol, but it can save you from hours of troubleshooting and investigation.

1. Limit the maximum number of prefixes that you learn from BGP peer, to avoid overload of your machine.
2. Deny updates that include a private AS number in the AS Path (64512 – 65535).
3. Use ACLs on your external interface to permit input/output BGP packets only from your defined source and destination
4. Limit TTL in BGP packets to limit the communication only with next-hop peers.
5. Use a password to authenticate peer neighbors.
6. Limit the maximum length of the AS path

Also here I would like to mention, not necessary as a security tip, but more like a best practice, enable when it is possible logging. This can help you to observe some strange behavior that occur on your machines where you are not arround them.

There is no topology present for this tutorial, but we will assume that we have a point-to-point serial connection between 2 routers, R2 (10.0.23.2) and R3 (10.0.23.3). Please click the image below to view the tutorial:

If for some reasons the tutorial above is not available for you, please check this text file which present in text mode everything needed to implement BGP security tips presented above.

Cisco: Engineer’s trick to avoid suboptimal path

I was explaining in the previous post what is the difference between optimal and suboptimal path and how to avoid the use of not such a good path in your routed environment. Also there I presented this so call “dirty trick” you can use to force the routing protocol to choose the path that you want, based on the Administrative distance modification.

As I said there is another way (for sure more than one) to do it, using a more elegant approach and from the networking point of view more safe considering the complex routing environment. I will use the same topology like in the previous post to offer you the possibility to compare these 2 methods presented and to choose the one that you understand and fit better to your needs. Also there are some other ways to do it and please feel free to discussed them in the comments section and maybe to present them here in a future post.

We will achive the desired results by setting one community on R1 for the advertised network 192.168.82.1 and dropping the prefixes, marked with the same community, on R2. Please be aware that for this method to work you have to allowed BGP peers to send communities list with the command “neighbor xx.xx.xx.xx send-community …” under “router bgp xxx” process.

Please see the example by clicking the image below:

Cisco: Dirty trick to force optimal path in routed environment

Everywhere in the world people try to find the optimal path to achieve something.If we speak about roads, trips and in our case networking, choosing the best path to an end point can have only advantages.

I took the term optimal / suboptimal path from the routing issues that can appear in the OSPF network environment and which are called by the experts suboptimal routing. What I want to explain here, maybe you already seen it, is that in some network environment the best path to a destination is not always preferred by the routing protocol due to some unhappy situations. To understand better what I’m talking here, please have a look at the topology that I will use for this tutorial and for the next one regarding optimal path.

In the example below I will show you a simple and dirty trick how you can escape from this situation. I recommend to use this dirty trick only in urgent cases and only temporary as this can lead to more problems if you have a complex network environment. In the next days I will show you a more elegant method to escape from suboptimal path problem.

As you can see in the topology we have a network environment formed by 4 routers. On R1 we have configured a BGP session with the peer R3 and OSPF with R2. Since the peers are in different autonomous systems the BGP session will be external. For OSPF this does not matter.The Loopback100 interface in R1 is advertised into BGP and OSPF, and it is learned by R2. On R2 the interface 192.168.82.1 arrives on BGP table and OSPF table, but since the Administrative Distance of the eBGP (20) is better that the one of OSPF (110) on the routing table will appear the route through R4. This is bad because without considering the obvious longer path through R4, we can see that the links between R2-R4 and R1-R3 are Serial interfaces and definitely with more limited bandwidth than FastEhernet interface R1-R2 (we assume that we do no have any QoS or other limitation). Last note before we begin, all the routing processes on the devices are completely configured and functional.

Cisco: BGP path selection for inbound traffic

In some previous post we saw how we can manipulate BGP paths using attributes for outgoing traffic. Today we will see how to use another BGP attribute, but this time for manipulating inbound traffic. First I would like to ask you to have a look into the topology file and also to check the config files (if you have a basic idea about how BGP is configured that you don’t need the config files).

From the table above:
we see that the attributes needed for inbound traffic manipulation are AS-Path and MED. Today we will use AS-Path for traffic manipulation (MED sometime in closer future).

Beside using BGP attributes, there are other ways to manipulate traffic and paths in a BGP environment, but usually this need that the provider will support your actions. As an example to understand, you can do route tagging in your network (for example in MPLS on your CE) and your ISP will apply rules based on different tags (on PE side), but this is out of the scope of this tutorial and will be discussed maybe in another tutorial.

For our test environment, that you see in the topology, we advertise everything into BGP domain, exactly as draw, so there will be no problems of reachability.

Please see the tutorial and explanations below: