BGP (Border Gateway Protocol) is one of the core protocols responsible for routing packets across the internet, so when it goes wrong, significant outages can occur. For example, in 2019, a small ISP made a BGP misconfiguration that unfortunately propagated upstream and took large parts of Cloudflare and AWS offline for over an hour. Also, a year earlier, a BGP hijack took place in order to intercept traffic to a well-known cryptocurrency wallet provider and steal the funds of unsuspecting customers.
BGPalerter is an open-source BGP network monitoring tool that can provide real-time alerts on BGP activity, including route visibility and new route announcements, as well as potentially nefarious activity such as route hijacks or route leaks.
Note: BGPalerter automatically ingests publicly available network routing information, meaning that it does not have to have any level of privileged access or integration into the network(s) that you wish to monitor. All monitoring is fully compliant with the Computer Misuse Act, Computer Fraud and Abuse Act, and other similar laws. However, it is recommended to responsibly disclose any relevant findings to the affected network operator.
In this tutorial, you’ll install and configure BGPalerter to monitor your important networks for potentially suspicious activity.
To complete this tutorial, you will need:
An Ubuntu 18.04 server set up by following the Initial Server Setup with Ubuntu 18.04, including a sudo non-root user.
One or more networks or devices that you wish to monitor, for example:
For each device or network you’ll need to identify either the individual IP address, IP address range, or Autonomous System number that it is part of. This is covered in Step 1.
Once you have these ready, log in to your server as your non-root user to begin.
In this step, you will identify the relevant details of the networks that you want to monitor.
BGPalerter can monitor based on individual IP addresses or network prefixes. It can also monitor entire networks based on their Autonomous System (AS) number, which is a globally unique identifier for a network owned by a particular administrative entity.
In order to find this information, you can use the IP-to-ASN WHOIS lookup service provided by threat intelligence service Team Cymru. This is a custom WHOIS server designed for looking up IP address and network routing information.
If you don’t already have
whois installed, you can install it using the following commands:
- sudo apt update
- sudo apt install whois
Once you’ve confirmed that
whois is installed, begin by performing a lookup for the IP address of your own server, using the
-h argument to specify a custom server:
- whois -h whois.cymru.com your-ip-address
This will output a result similar to the following, which shows the AS name and number that your server is a part of. This will usually be the AS of your server hosting provider, for example, DigitalOcean.
OutputAS | IP | AS Name 14061 | your-ip-address | DIGITALOCEAN-ASN, US
Next, you can perform a lookup to identify the network prefix/range that your server is a part of. You do this by adding the
-p argument to your request:
- whois -h whois.cymru.com " -p your-ip-address"
The output will be very similar to the previous command, but will now show the IP address prefix that the IP address of your server belongs to:
OutputAS | IP | BGP Prefix | AS Name 14061 | your-ip-address | 220.127.116.11/20 | DIGITALOCEAN-ASN, US
Finally, you can look up further details of the AS that your server is a part of, including the geographic region and allocation date.
Substitute in the AS number that you identified using the previous commands. You use the
-v argument to enable verbose output, which ensures that all relevant details are shown:
- whois -h whois.cymru.com " -v as14061"
The output will show further information about the AS:
OutputAS | CC | Registry | Allocated | AS Name 14061 | US | arin | 2012-09-25 | DIGITALOCEAN-ASN, US
You’ve identified key details about the network(s) that you wish to monitor. Keep a note of these details somewhere, as you’ll need them later on. Next, you’ll begin the setup of BGPalerter.
In this step, you will create a new non-privileged user account for BGPalerter, as the program doesn’t need to run with sudo/root privileges.
Firstly, create a new user with a disabled password:
- sudo adduser --disabled-password bgpalerter
You do not need to set up a password or SSH keys, as you’ll use this user only as a service account for running/maintaining BGPalerter.
Log in to the new user using
- sudo su bgpalerter
You’ll now be logged in as the new user:
cd command to move to the home directory of your new user:
bgpalerter@droplet:/home/user$ cd bgpalerter@droplet:~$
You’ve created a new non-privileged user for BGPalerter. Next, you will install and configure BGPalerter on your system.
In this step, you will install and configure BGPalerter. Make sure that you’re still logged in as your new non-privileged user.
Firstly, you need to identify the latest release of BGPalerter, in order to ensure that you download the most up-to-date version. Browse to the BGPalerter Releases page and take a copy of the download link for the most recent Linux x64 release.
You can now download a copy of BGPalerter using
wget, making sure to substitute in the correct download link:
- wget https://github.com/nttgin/BGPalerter/releases/download/v1.24.0/bgpalerter-linux-x64
Once the file has finished downloading, mark it as executable:
- chmod +x bgpalerter-linux-x64
Next, check that BGPalerter has been downloaded and installed successfully by checking the version number:
- ./bgpalerter-linux-x64 --version
This will output the current version number:
Before you can run BGPalerter properly, you’ll need to define the networks that you wish to monitor within a configuration file. Create and open the
prefixes.yml file in your favourite text editor:
- nano ~/prefixes.yml
In this config file, you’ll specify each of the individual IP addresses, IP address ranges, and AS numbers that you want to monitor.
Add the following example and adjust the configuration values as required by using the network information that you identified in Step 1:
your-ip-address/32: description: My Server asn: - 14061 ignoreMorespecifics: false 18.104.22.168/20: description: IP range for my Server asn: - 14061 ignoreMorespecifics: false options: monitorASns: '14061': group: default
You can monitor as many IP address ranges or AS numbers as you want. To monitor individual IP addresses, represent them using
/32 for IPv4, and
/128 for IPv6.
ignoreMorespecifics value is used to control whether BGPalerter should ignore activity for routes that are more specific (smaller) than the one that you’re monitoring. For example, if you’re monitoring a
/20 and a routing change is detected for a
/24 within it, this is considered to be more specific. In most cases, you don’t want to ignore these, however if you are monitoring a large network with multiple delegated customer prefixes, this may help to reduce background noise.
You can now run BGPalerter for the first time in order to begin monitoring your networks:
If BGPalerter starts successfully, you’ll see output similar to the following. Note that it can sometimes take a few minutes for the monitoring to begin:
OutputImpossible to load config.yml. A default configuration file has been generated. BGPalerter, version: 1.24.0 environment: production Loaded config: /home/bgpalerter/config.yml Monitoring 22.214.171.124/20 Monitoring your-ip-address/32 Monitoring AS 14061
BGPalerter will continue to run until you stop it using
In the next step, you will interpret some of the alerts that BGPalerter can generate.
In this step, you will review some example BGPalerter alerts. BGPalerter will output alerts to the main output feed, and also optionally to any additional reporting endpoints that can be configured within
config.yml, as described in the BGPalerter documentation.
By default, BGPalerter monitors and alerts on the following:
Route hijacks: occur when an AS announces a prefix that it is not permitted to, causing traffic to be erroneously routed. This could be either a deliberate attack, or an accidental configuration error.
Loss of route visibility: A route is considered visible when a majority of BGP routers on the internet are able to reliably route to it. Loss of visibility refers to your network potentially being unavailable, for example if your BGP peering has stopped working.
New sub-prefix announcements: is when an AS begins announcing a prefix that is smaller that what is anticipated. This could be indicative of an intended configuration change, an accidental misconfiguration, or in some cases an attack.
Activity within your AS: will usually refer to new route announcements. A route is considered “new” if BGPalerter doesn’t yet know about it.
Following are some example alerts, along with a short description of their meaning:
The prefix 203.0.113.0/24 is announced by AS64496 instead of AS65540
This alert shows evidence of a route hijack, where AS64496 has announced
203.0.113.0/24 when it is expected that this route would be announced by AS65540. This is a strong indicator of a misconfiguration leading to a route leak, or a deliberate hijack by an attacker.
The prefix 203.0.113.0/24 has been withdrawn. It is no longer visible from 6 peers
This alert shows that the
203.0.113.0/24 network is no longer visible. This could be because of an upstream routing issue, or a router has suffered a power failure.
A new prefix 203.0.113.0/25 is announced by AS64496. It should be instead 203.0.113.0/24 announced by AS64496
This alert shows that a more-specific prefix has been announced where it is not anticipated, for example by announcing a
/25 when only a
/24 is expected. This is most likely a misconfiguration, however in some cases could be evidence of a route hijack.
AS64496 is announcing 192.0.2.0/24 but this prefix is not in the configured list of announced prefixes
Finally, this alert shows that AS64496 has announced a prefix that BGPalerter does not yet know about. This could be because your are legitimately announcing a new prefix, or it could be indicative of a misconfiguration resulting in you accidentally announcing a prefix owned by someone else.
In this step, you reviewed some example BGPalerter alerts. Next, you’ll configure BGPalerter to run automatically at boot.
In this final step, you’ll configure BGPalerter to run at boot.
Ensure that you’re still logged in as your new non-privileged user, and then open the crontab editor:
- crontab -e
Next, add the following entry to the bottom of the crontab file:
@reboot sleep 10; screen -dmS bgpalerter "./bgpalerter-linux-x64"
Every time your system boots, this will create a detached
screen session called ‘bgpalerter’, and start BGPalerter within it.
Save and exit the crontab editor. You may now wish to reboot your system in order to make sure that BGPalerter correctly starts at boot.
You’ll first need to log out of your BGPalerter user:
Then proceed with a normal system reboot:
- sudo reboot
Once your system has rebooted, log back in to your server and use
su to access your BGPalerter user again:
- sudo su bgpalerter
You can then attach to the session at any time in order to view the output from BGPalerter:
- screen -r bgpalerter
In this final step, you configured BGPalerter to run at boot.
In this article you set up BGPalerter and used it to monitor networks for BGP routing changes.
If you wish to make BGPalerter more user-friendly, you can configure it to send alerts to a Slack channel via a webhook:
If you wish to learn more about BGP itself, but do not have access to a production BGP environment, you may enjoy using DN42 to experiment with BGP in a safe, isolated environment:
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.