Utilizing BGP Communities for traffic steering – part 1: Firewalls


I typically spend more time in the enterprise data center than most of our team members and this comes with its own unique set of problems. One discussion that seems to never fail to come up is “where do I put the Firewalls (FWs)?”. That is typically followed by I have a disaster recovery or backup site with FWs there as well. This inevitably leads to a state management problem. Let’s look at how we can utilize BGP to address this problem:

  • what is a BGP standard community
  • BGP best path selection process
  • how to utilize them to steer traffic

This is something most service providers deal with on a daily basis but can be new to an enterprise.

BGP Standard communities

A BGP community is a route attribute that, essentially provides extra information for someone to take action or glean information from the route such as where it came from (location, type, organizational role).

By definition, a community is a 32 bit number that can be included with a route and when utilizing the new community format is displayed as (0-65535):(0-65535). It is recommend to utilize the new community format versus the old community format which is just a number. It is typically to utilize $YOURASN:$VALUE such as 65000:1000 which would be a community within ASN 65000 to signify something such as 1000 came from datacenter 1. This insures that you know the community was originated by your organization.

There are some well known communities that have global meaning. BGP communities are also what is called an optional transitive BGP attribute meaning that they can be passed from autonomous system (ASN) to autonomous system. It is typically recommended to strip communities sent from other organizations to prevent interference with your local policy. Telia has a great looking glass utility (https://lg.telia.net)that gives information on the communities they’ve attached to your routes.

BGP path selection

Now that we know what is a community is lets look at the BGP path selection process. It’s not uncommon for vendors to have vendor specific selection criteria with “weight” being at the top. However, typically local preference is the first with highest being the best. Then locally originated, shortest AS path, origin check, and Multi Exit Discriminator (MED). There are more selection criteria than this but we will focus on local preference (LP) since it is at the top of the list.

Modifying local preference will ALWAYS beat one of the other criteria with the exception of a weight value where applicable. For example in a Cisco environment the highest weight will beat the LP, if the weight is equal it will move to LP.

You might have noticed that there is no “community” value in the path selection process. That is because we are going to combine the community value with a policy to take an action on a route. Let’s tie this back to firewalls, security zones, and policy in the next section.

Modifying behavior with communities and LP

There are two ways to extend a security zone through a firewall. You can either route and utilize a Virtual Routing and Forwarding instance (VRF) or switch and put the Switched Virtual Interface (SVI) on the firewall. Switching limits your options as you scale and is not recommended. For this reason we will focus on utilizing VRFs. In this case we have VRF blue with community 65000:1 and VRF Orange with community 65000:2. These are segregated by firewalls and have different security policy.

With two firewalls it is easy to introduce a state problem and have packets rejected because of invalid state. When a packet ingresses one firewall and egresses another this introduces the problem as firewall 2 does not have a session for the flow. “How come we don’t run an HA pair?” is a common question; these might already be an HA pair and you’re preparing for a migration, they’re different vendors, or they’re in different data centers completely.

So now I can tie communities and local preference (LP) together to pin flows to firewalls and manage state. I can raise or lower the LP based on the community to ensure routing always returns to the firewall with the active session state. If the firewalls are in different data centers you can even do this to move flows of the same security level below the firewalls and maintain state across the DCs. Doing so involves advanced network techniques and policy configurations which IParchitechs has successfully implemented in dozen of DCs in spite of vendor attestation that this is not feasible.

MikroTik and Ubiquity routers being Hijacked by Dyre Malware?


[adrotate banner=”4″]


Came across several interesting articles that claim there is a change in the way Dyre aka Upatre malware is spreading. Dyre seems to be getting a lot of press as it is used in browser hijacks to compromise online banking credentials and other sensitive private data. However, most recently – instead of infecting hosts, it appears to be compromising routers as well.  Blogger krebsonsecurity.com writes:

Recently, researchers at the Fujitsu Security Operations Center in Warrington, UK began tracking Upatre being served from hundreds of compromised home routers — particularly routers powered by MikroTik and Ubiquiti’s AirOS.

As I first started researching this, I was wondering how they determined the router itself is compromised and not a host that sits on a NAT behind the router. Certainly different devices leave telltale signs visible in an IP packet capture that help point towards the true origin of a packet, so it’s possible that something was discovered in that way. It’s also possible the router isn’t being compromised via the Internet, but rather on the LAN side as it would be much easier for malware to scan the private subnet it sits on and attempt to use well known default credentials to login and take control of a router. While concerning, this LAN attack vector theory relies on the user not properly securing the router and doesn’t indicate a vulnerability in the operating system of either router.

However…I then came across this thread at the Ubiquity forums:


Apparently the attackers are taking advantage of routers that are in fact open and have storage that can be utilized so that it can serve as a distribution point for the malware and also as a C&C point to initiate attacks. In the thread the vulnerable code version that is mentioned is firmware version XW.v5.5.6. It’s not exactly clear what makes this vulnerable, but from reading the forum it seems likely that the firewall may not be enabled by default and with the credentials unchanged, it becomes a target for Dyre. Somebody with more experience in Ubiquity may be able to comment further as I don’t spend enough time with Ubiquity to know for sure across the various code versions.

Example of Dyre using an ubiquity router to initiate attacks…the ./win9 processes are Dyre

Mem: 58492K used, 3632K free, 0K shrd, 764K buff, 6588K cached
CPU:   0% usr   2% sys   0% nice  92% idle   0% io   0% irq   4% softirq
Load average: 0.03 0.06 0.01
15472 15355 ubnt     R     1992   3%   1% top
 2746  2724 ubnt     S    25400  41%   0% ./win9
 2742  2724 ubnt     S    25400  41%   0% ./win9
 2739  2724 ubnt     S    25400  41%   0% ./win9
 2744  2724 ubnt     S    25400  41%   0% ./win9
 2745  2724 ubnt     S    25400  41%   0% ./win9
 2738  2724 ubnt     S    25400  41%   0% ./win9
 2743  2724 ubnt     S    25400  41%   0% ./win9
 2737  2724 ubnt     S    25400  41%   0% ./win9
 3128  2919 ubnt     S    94836 152%   0% ./i
 3112  2919 ubnt     S    94836 152%   0% ./i
 3103  2919 ubnt     S    94836 152%   0% ./i
 3106  2919 ubnt     S    94836 152%   0% ./i
 3102  2919 ubnt     S    94836 152%   0% ./i
 3087  2919 ubnt     S    94836 152%   0% ./i
 3129  2919 ubnt     S    94836 152%   0% ./i
 3137  2919 ubnt     S    94836 152%   0% ./i
 3104  2919 ubnt     S    94836 152%   0% ./i
 3113  2919 ubnt     S    94836 152%   0% ./i
 3135  2919 ubnt     S    94836 152%   0% ./i

MikroTik’s response

There is a thread on this at the MIkroTik forums and MikroTik’s official response below is that this is mostly hype and there isn’t a major threat. Which seems to be true if your router is properly secured with a firewall and you change the default credentials.  MikroTik routers definitely come with the firewall enabled to protect the less tech-savvy or forgetful users.



Neither vendor seems to have a vulnerability that exposes serious code flaws. The answer to this is an oldie but a goodie – be sure to properly set the firewall and use complex credentials on Internet facing routers.




This blog is sponsored by

iparchitechs_managed_services - 317dpi

For MikroTik consulting, integration and design, please contact [email protected]