Archive

Category Archives for "BGPmon"

Hijack event today by Indosat

Today we observed a large-scale ‘hijack’ event that affected many of the prefixes on the Internet. This blog post is to provide you with some additional information.

What happened?
Indosat, AS4761, one of Indonesia’s largest telecommunication networks normally originates about 300 prefixes. Starting at 18:26 UTC (April 2, 2014) AS4761 began to originate 417,038 new prefixes normally announced by other Autonomous Systems such as yours. The ‘mis-origination’ event by Indosat lasted for several hours affecting different prefixes at different times until approximately 21:15 UTC.

What caused this?
Given the large scale of this event we presume this is not malicious or intentional but rather the result of an operational issue. Other sources report this was the result of a maintenance window gone bad. Interestingly we documented a similar event involving Indosat in 2011, more details regarding that incident can be found here: http://www.bgpmon.net/hijack-by-as4761-indosat-a-quick-report/

Impact
The impact of this event was different per network, many of the hijacked routes were seen by several providers in Thailand. This means that it’s likely that communication between these providers in Thailand (as well as Indonesia) and your prefix may have been affected.
One of the heuristics we look at to determine the Continue reading

Turkey Hijacking IP addresses for popular Global DNS providers

At BGPmon we see numerous BGP hijacks every single day, some are interesting because of the size and scale of the hijack or as we’ve seen today because of the targeted hijacked prefixes. 
It all started last weekend when the Turkish president ordered the censorship of twitter.com. This started with a block of twitter by returning false twitter IP addresses by Turk Telekom DNS servers.  Soon users in Turkey discovered that changing DNS providers to Google DNS or OpenDNS was a good method of bypassing the censorship.
But as of around 9am UTC today (Saturday March 29) this changed when Turk Telekom started to hijack the IP address for popular free and open DNS providers such as Google’s 8.8.8.8, OpenDNS’ 208.67.222.222 and Level3’s 4.2.2.2.

BGP hijack
Using the Turk Telekom looking glass we can see that AS9121 (Turk Telekom) has specific /32 routes for these IP addresses. Since this is the most specific route possible for an IPv4 address, this route will always be selected and the result is that traffic for this IP address is sent to this new bogus route.

Turk Telekom route server displaying the hijacked route

Turk Telekom route server displaying the Continue reading

Looking at the spamhaus DDOS from a BGP perspective

It’s been a busy week for network engineers world wide, rerouting around broken optical links and of course the 300Gb/s DDOS attack towards Spamhaus and Cloudflare. This DDOS has been classified as the largest DDOS attack ever recorded and has been written about quite a bit in mainstream media.

There’s been a bit of discussion about how much this DDOS actually slowed down the Internet globally. Fact is that the Internet didn’t come to a halt but the large amount of new traffic that had to be handled by some of the carriers did result in congestion and significant packet loss by some of the Tier1 carriers last weekend. In this blog post we’ll look at this event from the routing perspective, what effects did this have on the Internet Exchanges and we’ll also look at some BGP hijacks related to this attack.

BGP hijack affecting Spamhause
The majority of the attack towards SpamHaus and cloudflare was a brute-force DDOS of attack. But in an attempt to affect spamhause services different techniques were used, one of them was a BGP hijack by the alleged initiator of the attack. Greenhost.nl has a great description on their blog about how AS34109 Continue reading

Accidentally stealing the Internet

Just a few days ago we learned  about an incident involving a mis-issued SSL certificate that was used in a Man in the Middle attack to intercept Gmail data. In this blog post we’ll talk about how Man in the Middle (MITM) attacks work and we’ll look at recent BGP MITM event that caused traffic for some major networks such as Microsoft and Facebook to be redirected to an ISP in France.

Certificate authorities and SSL
Just as the DigiNotar storm seemed to have calmed down, Google announced they discovered, yet another Certificate Authority that was involved in a similar incident. TURKTRUST, a certificate authority, mis-issued two intermediate certificates that were later used to intercept SSL traffic to Gmail. In cases like this the attacker is interested in intercepting communication between Gmail users and the Gmail servers. In order to successfully execute such an attack the attacker will need to insert his fake Gmail impersonating webserver between the user and the actual Gmail servers, this is what we call a Man in the Middle Attack, sometimes referred to as MITM.
The challenge here is: how do you get the user to send traffic to your fake server instead of to the Continue reading

Syria shuts down the Internet

As of 10:27 UTC this morning the majority of the Internet in Syria is no longer connected to the rest of the world and can be considered as offline. Syria has only one major provider, AS29256 The Syrian Telecommunications Establishment. This provider is government owned and originates 56 out of 62 Syrian prefixes.

This morning between 10:26 and 10:27 all routes originated by AS29256 (The Syrian Telecommunications Establishment) were withdrawn and became unreachable.
The only Syrian prefixes left in the routing table are 5 prefixes originated by TATA, AS6453. These are the prefixes that are still reachable via TATA:
216.6.0.0/23, 63.243.163.0/24, 116.0.72.0/22, 66.198.39.0/24, 66.198.41.0/24

What happened?
We have no official confirmation about what happened, but similar events in the past [Syria, Egypt] were all government ordered. Because the primary telecom provider is state controlled in Syria, an outage like this is relatively easy to implement by ordering the primary telecom provider to shutdown the external links or BGP sessions with the external providers. External providers that provide services to Syria are:
AS9121 Turk Telecom
AS6762 telecom Italia
AS3491 PCCW Global
AS6453 Tata
Not the first outage

New version of BGPmon.net

As many of you are aware, BGPmon.net has been offered as a free service since becoming publically available in 2008. From its inception the service has been funded largely by myself. Now, due to ever-increasing popularity, it has become unsustainable to run the service on personal funds and my available time. I have reached a branch in the road: BGPmon.net must either become financially self-supporting, reduce its scope or cease. Clearly the latter options would waste the project’s potential and accomplishments.

So I’m happy to announce that as of today BGPmon.net services will be available in two flavors: a free ‘entry level’ service and a full-featured premium commercial service.

With these changes, BGPmon.net will become more sustainable and provide better support, and allow us to continue improving services while adding new features.

What to expect
Our base services remain free, but with a limited feature set and up to 5 prefixes per account.

The premium commercial service allows you to monitor as many prefixes as needed and provides the full-feature set on a new powerful platform. The routing report, SOAP API and additional email address features are now part of the premium service. Pricing details can Continue reading

A BGP leak made in Canada

A BGP leak made in Canada

Today many network operators saw their BGP session flap, RTT’s increase and CPU usage on routers spike.  While looking at our BGP data we determined the root cause to be a large BGP leak in Canada that quickly affected networks worldwide.

Dery Telecom
Based on our analysis it seems that Canadian ISP Dery Telecom Inc (AS46618) is the cause of what we observed today. AS46618 is dual homed to both VIDEOTRON and Bell. What seems to have happened is that AS46618 leaked routes learned from VIDEOTRON to Bell. This in itself is not unique and happens relatively often. However normally transit ISP’s like Bell have strict filters applied on these BGP sessions, limiting the number of prefixes they accept from their customers. In this case the filter failed to work or simply wasn’t (correctly) applied by both Bell and Dery Telecom.

Sequence of events
At 17:27 UTC  AS46618 ( Dery Telecom Inc) started to leak a ‘full table’, or at least a significant chunk of it to its provider Bell AS577. Bell selected 107,409 of these routes as best routes. Even though many of the ASpaths were much longer than other alternatives it Continue reading