Re: "Defensive" BGP hijacking?
Hello Everyone, I would like to give as much insight as I can in regards to the BGP hijack being discussed in this thread. I won’t be going into specific details of the attack, but we do plan to release more information on our website when we are able to. I also wanted to let Hugo (who started the thread) know that we harbor no hard feelings about bringing this topic up, as it is relevant to the community and does warrant discussion. Hugo, you may owe me a beer the next time we meet. :) We agree with others that NANOG is the most appropriate venue to answer any questions and discuss the topic at hand. I have been attending NANOG for the past 3-4 years, and I can assure you that it is of the utmost importance to me how the community views my company, my employees, and myself. There are many people in this community that I personally have the upmost respect for, and it would sadden me If I were to lose the respect of mentors, colleagues, and friends by not responding. That being said, I think there are a fair number of people in NANOG that would vouch for my character and ethics relating to the intent of my actions, even if I were to remain silent. I would also like to preface that my explanation of the events that occurred and actions taken by BackConnect are not to justify or provide excuses. My goal is to simply show what happened and give insight into our actions. I will start with a little background to bring anyone up to speed that is not aware of the events that transpired. *About the company, BackConnect, Inc.*: We are a new (~4 months old) open-sourced based DDoS mitigation and network security provider that specializes in custom intrusion detection and prevention systems. We also provide threat intelligence services, with an emphasis on active botnets, new and upcoming DDoS attack patterns, and boot services. From time to time, this information flows through our network for collection purposes. *Events leading to the Hijack*: On 9/6/2016, ~10:30AM PST, one of our clients and our website received a large and relatively sophisticated DDoS attack. The attack targeted entire subnets and peaked over 200 Gbps and 40Mpps. Although the attack was automatically detected and mostly filtered, there was initially a small leak. In response we quickly applied new security rules that rendered it entirely ineffective. The attackers continued to attack our network and client for roughly 6 hours before giving up. *Events that caused us to perform the BGP hijack*: After the DDoS attacks subsided, the attackers started to harass us by calling in using spoofed phone numbers. Curious to what this was all about, we fielded various calls which allowed us to ascertain who was behind the attacks by correlating e-mails with the information they provided over the phone. Throughout the day and late into the night, these calls and threats continued to increase in number. Throughout these calls we noticed an increasing trend of them bringing up personal information of myself and employees. At this point I personally filled a police report in preparation to a possible SWATing attempt. As they continued to harass our company, more and more red flags indicated that I would soon be targeted. This was the point where I decided I needed to go on the offensive to protect myself, my partner, visiting family, and my employees. The actions proved to be extremely effective, as all forms of harassment and threats from the attackers immediately stopped. In addition to our main objective, we were able to collect intelligence on the actors behind the bot net as well as identify the attack servers used by the booter service. *Afterthoughts*: The decision to hijack the attackers IP space was not something I took lightly. I was fully aware there were services that reported such actions and knew that this could potentially be brought up in discussion and hurt BackConnect’s image. Even though we had the capacity to hide our actions, we felt that it would be wrong to do so. I have spent a long time reflecting on my decision and how it may negatively impact the company and myself in some people’s eyes, but ultimately I stand by it. The experience and feedback I have gained from these events has proven invaluable and will be used to shape the policies surrounding the future handling of similar situations. I am happy to field questions, but cannot promise any answers, disclosure of further information, or when they will be responded to. Sincerely, Bryant Townsend
On Tuesday, September 13, 2016, Bryant Townsend <bryant@backconnect.com> wrote:
Hello Everyone,
I would like to give as much insight as I can in regards to the BGP hijack being discussed in this thread. I won’t be going into specific details of the attack, but we do plan to release more information on our website when we are able to. I also wanted to let Hugo (who started the thread) know that we harbor no hard feelings about bringing this topic up, as it is relevant to the community and does warrant discussion. Hugo, you may owe me a beer the next time we meet. :)
We agree with others that NANOG is the most appropriate venue to answer any questions and discuss the topic at hand. I have been attending NANOG for the past 3-4 years, and I can assure you that it is of the utmost importance to me how the community views my company, my employees, and myself. There are many people in this community that I personally have the upmost respect for, and it would sadden me If I were to lose the respect of mentors, colleagues, and friends by not responding. That being said, I think there are a fair number of people in NANOG that would vouch for my character and ethics relating to the intent of my actions, even if I were to remain silent. I would also like to preface that my explanation of the events that occurred and actions taken by BackConnect are not to justify or provide excuses. My goal is to simply show what happened and give insight into our actions.
I will start with a little background to bring anyone up to speed that is not aware of the events that transpired.
*About the company, BackConnect, Inc.*: We are a new (~4 months old) open-sourced based DDoS mitigation and network security provider that specializes in custom intrusion detection and prevention systems. We also provide threat intelligence services, with an emphasis on active botnets, new and upcoming DDoS attack patterns, and boot services. From time to time, this information flows through our network for collection purposes.
*Events leading to the Hijack*: On 9/6/2016, ~10:30AM PST, one of our clients and our website received a large and relatively sophisticated DDoS attack. The attack targeted entire subnets and peaked over 200 Gbps and 40Mpps. Although the attack was automatically detected and mostly filtered, there was initially a small leak. In response we quickly applied new security rules that rendered it entirely ineffective. The attackers continued to attack our network and client for roughly 6 hours before giving up.
*Events that caused us to perform the BGP hijack*: After the DDoS attacks subsided, the attackers started to harass us by calling in using spoofed phone numbers. Curious to what this was all about, we fielded various calls which allowed us to ascertain who was behind the attacks by correlating e-mails with the information they provided over the phone. Throughout the day and late into the night, these calls and threats continued to increase in number. Throughout these calls we noticed an increasing trend of them bringing up personal information of myself and employees. At this point I personally filled a police report in preparation to a possible SWATing attempt. As they continued to harass our company, more and more red flags indicated that I would soon be targeted. This was the point where I decided I needed to go on the offensive to protect myself, my partner, visiting family, and my employees. The actions proved to be extremely effective, as all forms of harassment and threats from the attackers immediately stopped. In addition to our main objective, we were able to collect intelligence on the actors behind the bot net as well as identify the attack servers used by the booter service.
*Afterthoughts*: The decision to hijack the attackers IP space was not something I took lightly. I was fully aware there were services that reported such actions and knew that this could potentially be brought up in discussion and hurt BackConnect’s image. Even though we had the capacity to hide our actions, we felt that it would be wrong to do so. I have spent a long time reflecting on my decision and how it may negatively impact the company and myself in some people’s eyes, but ultimately I stand by it. The experience and feedback I have gained from these events has proven invaluable and will be used to shape the policies surrounding the future handling of similar situations. I am happy to field questions, but cannot promise any answers, disclosure of further information, or when they will be responded to.
Sincerely,
Bryant Townsend
Will you do the bgp hijacking in the future: yes or no? Thanks!
+1 to this question. Bryant, thanks for giving us your side of this story. Matt Freitag Network Engineer I Information Technology Michigan Technological University (906) 487-3696 <%28906%29%20487-3696> https://www.mtu.edu/ https://www.it.mtu.edu/ On Tue, Sep 13, 2016 at 12:22 PM, Ca By <cb.list6@gmail.com> wrote:
On Tuesday, September 13, 2016, Bryant Townsend <bryant@backconnect.com> wrote:
Hello Everyone,
I would like to give as much insight as I can in regards to the BGP hijack being discussed in this thread. I won’t be going into specific details of the attack, but we do plan to release more information on our website when we are able to. I also wanted to let Hugo (who started the thread) know that we harbor no hard feelings about bringing this topic up, as it is relevant to the community and does warrant discussion. Hugo, you may owe me a beer the next time we meet. :)
We agree with others that NANOG is the most appropriate venue to answer any questions and discuss the topic at hand. I have been attending NANOG for the past 3-4 years, and I can assure you that it is of the utmost importance to me how the community views my company, my employees, and myself. There are many people in this community that I personally have the upmost respect for, and it would sadden me If I were to lose the respect of mentors, colleagues, and friends by not responding. That being said, I think there are a fair number of people in NANOG that would vouch for my character and ethics relating to the intent of my actions, even if I were to remain silent. I would also like to preface that my explanation of the events that occurred and actions taken by BackConnect are not to justify or provide excuses. My goal is to simply show what happened and give insight into our actions.
I will start with a little background to bring anyone up to speed that is not aware of the events that transpired.
*About the company, BackConnect, Inc.*: We are a new (~4 months old) open-sourced based DDoS mitigation and network security provider that specializes in custom intrusion detection and prevention systems. We also provide threat intelligence services, with an emphasis on active botnets, new and upcoming DDoS attack patterns, and boot services. From time to time, this information flows through our network for collection purposes.
*Events leading to the Hijack*: On 9/6/2016, ~10:30AM PST, one of our clients and our website received a large and relatively sophisticated DDoS attack. The attack targeted entire subnets and peaked over 200 Gbps and 40Mpps. Although the attack was automatically detected and mostly filtered, there was initially a small leak. In response we quickly applied new security rules that rendered it entirely ineffective. The attackers continued to attack our network and client for roughly 6 hours before giving up.
*Events that caused us to perform the BGP hijack*: After the DDoS attacks subsided, the attackers started to harass us by calling in using spoofed phone numbers. Curious to what this was all about, we fielded various calls which allowed us to ascertain who was behind the attacks by correlating e-mails with the information they provided over the phone. Throughout the day and late into the night, these calls and threats continued to increase in number. Throughout these calls we noticed an increasing trend of them bringing up personal information of myself and employees. At this point I personally filled a police report in preparation to a possible SWATing attempt. As they continued to harass our company, more and more red flags indicated that I would soon be targeted. This was the point where I decided I needed to go on the offensive to protect myself, my partner, visiting family, and my employees. The actions proved to be extremely effective, as all forms of harassment and threats from the attackers immediately stopped. In addition to our main objective, we were able to collect intelligence on the actors behind the bot net as well as identify the attack servers used by the booter service.
*Afterthoughts*: The decision to hijack the attackers IP space was not something I took lightly. I was fully aware there were services that reported such actions and knew that this could potentially be brought up in discussion and hurt BackConnect’s image. Even though we had the capacity to hide our actions, we felt that it would be wrong to do so. I have spent a long time reflecting on my decision and how it may negatively impact the company and myself in some people’s eyes, but ultimately I stand by it. The experience and feedback I have gained from these events has proven invaluable and will be used to shape the policies surrounding the future handling of similar situations. I am happy to field questions, but cannot promise any answers, disclosure of further information, or when they will be responded to.
Sincerely,
Bryant Townsend
Will you do the bgp hijacking in the future: yes or no?
Thanks!
What would you have done if the personal harassment didn't stop? What would you have done if they simply switched to a new source range/different set of bots? Seems like a very slippery slope to me. Spencer Ryan | Senior Systems Administrator | sryan@arbor.net<mailto:sryan@arbor.net> Arbor Networks +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com<http://www.arbornetworks.com/> ________________________________ From: NANOG <nanog-bounces@nanog.org> on behalf of Bryant Townsend <bryant@backconnect.com> Sent: Tuesday, September 13, 2016 3:22:43 AM To: nanog@nanog.org Subject: Re: "Defensive" BGP hijacking? Hello Everyone, I would like to give as much insight as I can in regards to the BGP hijack being discussed in this thread. I won’t be going into specific details of the attack, but we do plan to release more information on our website when we are able to. I also wanted to let Hugo (who started the thread) know that we harbor no hard feelings about bringing this topic up, as it is relevant to the community and does warrant discussion. Hugo, you may owe me a beer the next time we meet. :) We agree with others that NANOG is the most appropriate venue to answer any questions and discuss the topic at hand. I have been attending NANOG for the past 3-4 years, and I can assure you that it is of the utmost importance to me how the community views my company, my employees, and myself. There are many people in this community that I personally have the upmost respect for, and it would sadden me If I were to lose the respect of mentors, colleagues, and friends by not responding. That being said, I think there are a fair number of people in NANOG that would vouch for my character and ethics relating to the intent of my actions, even if I were to remain silent. I would also like to preface that my explanation of the events that occurred and actions taken by BackConnect are not to justify or provide excuses. My goal is to simply show what happened and give insight into our actions. I will start with a little background to bring anyone up to speed that is not aware of the events that transpired. *About the company, BackConnect, Inc.*: We are a new (~4 months old) open-sourced based DDoS mitigation and network security provider that specializes in custom intrusion detection and prevention systems. We also provide threat intelligence services, with an emphasis on active botnets, new and upcoming DDoS attack patterns, and boot services. From time to time, this information flows through our network for collection purposes. *Events leading to the Hijack*: On 9/6/2016, ~10:30AM PST, one of our clients and our website received a large and relatively sophisticated DDoS attack. The attack targeted entire subnets and peaked over 200 Gbps and 40Mpps. Although the attack was automatically detected and mostly filtered, there was initially a small leak. In response we quickly applied new security rules that rendered it entirely ineffective. The attackers continued to attack our network and client for roughly 6 hours before giving up. *Events that caused us to perform the BGP hijack*: After the DDoS attacks subsided, the attackers started to harass us by calling in using spoofed phone numbers. Curious to what this was all about, we fielded various calls which allowed us to ascertain who was behind the attacks by correlating e-mails with the information they provided over the phone. Throughout the day and late into the night, these calls and threats continued to increase in number. Throughout these calls we noticed an increasing trend of them bringing up personal information of myself and employees. At this point I personally filled a police report in preparation to a possible SWATing attempt. As they continued to harass our company, more and more red flags indicated that I would soon be targeted. This was the point where I decided I needed to go on the offensive to protect myself, my partner, visiting family, and my employees. The actions proved to be extremely effective, as all forms of harassment and threats from the attackers immediately stopped. In addition to our main objective, we were able to collect intelligence on the actors behind the bot net as well as identify the attack servers used by the booter service. *Afterthoughts*: The decision to hijack the attackers IP space was not something I took lightly. I was fully aware there were services that reported such actions and knew that this could potentially be brought up in discussion and hurt BackConnect’s image. Even though we had the capacity to hide our actions, we felt that it would be wrong to do so. I have spent a long time reflecting on my decision and how it may negatively impact the company and myself in some people’s eyes, but ultimately I stand by it. The experience and feedback I have gained from these events has proven invaluable and will be used to shape the policies surrounding the future handling of similar situations. I am happy to field questions, but cannot promise any answers, disclosure of further information, or when they will be responded to. Sincerely, Bryant Townsend
Bryant Townsend wrote on 9/13/2016 2:22 AM:
This was the point where I decided I needed to go on the offensive to protect myself, my partner, visiting family, and my employees. The actions proved to be extremely effective, as all forms of harassment and threats from the attackers immediately stopped.
Bryant, what actions, exactly, did you take? This topic seems intentionally glossed over while you spend a much larger amount of time explaining the back story and your motivations rather than your actions. Questions I was left with: 1. What prefixes have you announced without permission (not just this event)? 2. How did you identify these prefixes? 3. Did you attempt to contact the owner of these prefixes? 4. Did you attempt to contact the origin or transit AS of these prefixes? 5. What was the process to get your upstream AS to accept these prefix announcements? 6. Was your upstream AS complicit in allowing you to announce prefixes you did not have authorization to announce?
Blake, I concur that these are key questions. Probably _the_ key questions. The fabric of the Internet is today based on trust, and BGP's integrity is the core of that trust. I realize that BGP hijacking is not uncommon. However, this is the first time I've seen in it used defensively. I don't see a way to ever bless this kind of defensive use without compromising that core trust. If Internet reachability depends on individual providers believing that they are justified in violating that trust when they are attacked, how can the Internet stand? In addition to the question posed to Bryant about whether he would take this action again, I would like to add: what about the innocent parties impacted by your actions? Or do you take the position there were no innocent parties in the hijacked prefixes? -mel via cell
On Sep 13, 2016, at 11:40 AM, Blake Hudson <blake@ispn.net> wrote:
Bryant Townsend wrote on 9/13/2016 2:22 AM:
This was the point where I decided I needed to go on the offensive to protect myself, my partner, visiting family, and my employees. The actions proved to be extremely effective, as all forms of harassment and threats from the attackers immediately stopped.
Bryant, what actions, exactly, did you take? This topic seems intentionally glossed over while you spend a much larger amount of time explaining the back story and your motivations rather than your actions.
Questions I was left with:
1. What prefixes have you announced without permission (not just this event)? 2. How did you identify these prefixes? 3. Did you attempt to contact the owner of these prefixes? 4. Did you attempt to contact the origin or transit AS of these prefixes? 5. What was the process to get your upstream AS to accept these prefix announcements? 6. Was your upstream AS complicit in allowing you to announce prefixes you did not have authorization to announce?
If only there were a global system, with consistent and verifiable security properties, to permit address holders to declare the set of AS's authorized to announce their prefixes, and routers anywhere on the Internet to independently verify the corresponding validity of received announcements. *cough https://www.nanog.org/meetings/abstract?id=2846 cough* I now return us to our discussion of network police, questionnaires for network security, and the use of beer as a motivating force. dougm On Tue, Sep 13, 2016 at 2:51 PM, Mel Beckman <mel@beckman.org> wrote:
Blake,
I concur that these are key questions. Probably _the_ key questions. The fabric of the Internet is today based on trust, and BGP's integrity is the core of that trust.
I realize that BGP hijacking is not uncommon. However, this is the first time I've seen in it used defensively. I don't see a way to ever bless this kind of defensive use without compromising that core trust. If Internet reachability depends on individual providers believing that they are justified in violating that trust when they are attacked, how can the Internet stand?
In addition to the question posed to Bryant about whether he would take this action again, I would like to add: what about the innocent parties impacted by your actions? Or do you take the position there were no innocent parties in the hijacked prefixes?
-mel via cell
On Sep 13, 2016, at 11:40 AM, Blake Hudson <blake@ispn.net> wrote:
Bryant Townsend wrote on 9/13/2016 2:22 AM:
This was the point where I decided I needed to go on the offensive to protect myself, my partner, visiting family, and my employees. The actions proved to be extremely effective, as all forms of harassment and threats from the attackers immediately stopped.
Bryant, what actions, exactly, did you take? This topic seems intentionally glossed over while you spend a much larger amount of time explaining the back story and your motivations rather than your actions.
Questions I was left with:
1. What prefixes have you announced without permission (not just this event)? 2. How did you identify these prefixes? 3. Did you attempt to contact the owner of these prefixes? 4. Did you attempt to contact the origin or transit AS of these prefixes? 5. What was the process to get your upstream AS to accept these prefix announcements? 6. Was your upstream AS complicit in allowing you to announce prefixes you did not have authorization to announce?
-- DougM at Work
On Tuesday, September 13, 2016, Doug Montgomery <dougm.work@gmail.com> wrote:
If only there were a global system, with consistent and verifiable security properties, to permit address holders to declare the set of AS's authorized to announce their prefixes, and routers anywhere on the Internet to independently verify the corresponding validity of received announcements.
*cough https://www.nanog.org/meetings/abstract?id=2846 cough*
I now return us to our discussion of network police, questionnaires for network security, and the use of beer as a motivating force.
dougm
Interesting that backconnect has invalid ROA issued http://bgp.he.net/AS203959#_prefixes On Tue, Sep 13, 2016 at 2:51 PM, Mel Beckman <mel@beckman.org <javascript:;>>
wrote:
Blake,
I concur that these are key questions. Probably _the_ key questions. The fabric of the Internet is today based on trust, and BGP's integrity is the core of that trust.
I realize that BGP hijacking is not uncommon. However, this is the first time I've seen in it used defensively. I don't see a way to ever bless this kind of defensive use without compromising that core trust. If Internet reachability depends on individual providers believing that they are justified in violating that trust when they are attacked, how can the Internet stand?
In addition to the question posed to Bryant about whether he would take this action again, I would like to add: what about the innocent parties impacted by your actions? Or do you take the position there were no innocent parties in the hijacked prefixes?
-mel via cell
On Sep 13, 2016, at 11:40 AM, Blake Hudson <blake@ispn.net <javascript:;>> wrote:
Bryant Townsend wrote on 9/13/2016 2:22 AM:
This was the point where I decided I needed to go on the offensive to protect myself, my partner, visiting family, and my employees. The actions proved to be extremely effective, as all forms of harassment and threats from the attackers immediately stopped.
Bryant, what actions, exactly, did you take? This topic seems intentionally glossed over while you spend a much larger amount of time explaining the back story and your motivations rather than your actions.
Questions I was left with:
1. What prefixes have you announced without permission (not just this event)? 2. How did you identify these prefixes? 3. Did you attempt to contact the owner of these prefixes? 4. Did you attempt to contact the origin or transit AS of these prefixes? 5. What was the process to get your upstream AS to accept these prefix announcements? 6. Was your upstream AS complicit in allowing you to announce prefixes you did not have authorization to announce?
-- DougM at Work
On Sep 13, 2016, at 8:08 PM, Ca By <cb.list6@gmail.com> wrote:
On Tuesday, September 13, 2016, Doug Montgomery <dougm.work@gmail.com> wrote:
If only there were a global system, with consistent and verifiable security properties, to permit address holders to declare the set of AS's authorized to announce their prefixes, and routers anywhere on the Internet to independently verify the corresponding validity of received announcements.
*cough https://www.nanog.org/meetings/abstract?id=2846 cough*
I now return us to our discussion of network police, questionnaires for network security, and the use of beer as a motivating force.
dougm
Interesting that backconnect has invalid ROA issued
Well, no, that’s not what the bgp.he.net (live long and prosper!) icons mean. There is nothing invalid about the ROA. And BackConnect did not issue it. The red key means that AS203959 BackConnect Security LLC is announcing routes for 181.215.239.0/24, 191.96.128.0/24. etc that are invalid according to the RPKI. Someone else with the right to use 181.215.239.0/24, 191.96.128.0/24. etc, created ROAs authorizing some other AS(s) to originate the route. You can look at the ROAs for those prefixes with red keys in http://rpki-browser.realmv6.org (and with the RPKIviz and EOM tools from www.securerouting.net). You can see that there are ROAs for 181.214.0.0/15 for AS50673, AS60458, AS61440. and ROAs for 191.96.0.0/16 for AS61440, AS60458, AS29073, AS33182, AS37692. and ROAs for 191.101.0.0/16 for AS60458, AS37692, AS61440. Except. It looks like, maybe, BackConnect was re-allocated the four prefixes with red keys, and whoever reallocated the prefixes to them created ROAs for their aggregate — but not for their customers. See for example http://bgp.he.net/net/191.96.128.0/24 (and http://bgp.he.net/net/191.101.191.0/24) This can occurred as the world backfills the existing allocations and the customers don’t keep up and their providers aren’t careful. Some RPKI implementations will warn you that the ROA you are about to create will make existing routes appear invalid to the RPKI. Just for fun, take a look at the IRR entries for the four prefixes with red key icons: route: 191.96.128.0/24 descr: Clan Servers origin: AS20473 notify: net-support@ap.equinix.com notify: noc@ap.equinix.com mnt-by: MAINT-EQUINIXPAC changed: mvillalobos@ap.equinix.com 20151229 source: NTTCOM route: 191.96.129.0/24 descr: Clan Servers origin: AS20473 notify: net-support@ap.equinix.com notify: noc@ap.equinix.com mnt-by: MAINT-EQUINIXPAC changed: mvillalobos@ap.equinix.com 20151229 source: NTTCOM route: 191.101.191.0/24 descr: Clan Servers origin: AS20473 notify: net-support@ap.equinix.com notify: ap-noc@ap.equinix.com mnt-by: MAINT-EQUINIXPAC changed: mporquez@ap.equinix.com 20151227 source: NTTCOM route: 181.215.239.0/24 descr: Proxy route object registered by AS2764 origin: AS45177 remarks: This route object was created by AAPT on behalf of a customer. remarks: As some of AAPTs upstream networks filter based on IRR objects, remarks: this route object has been created to ensure that the advertisement remarks: of this prefix is not rejected. notify: routing.shared@aapt.com.au mnt-by: MAINT-AS2764 changed: nobody@aapt.com.au 20160106 source: RADB (like the “nobody” part???) At least the aggregate announcements aren’t proxies. route: 181.214.0.0/19 descr: Digital Energy Technologies LTD. origin: AS61440 mnt-by: MAINT-AS61440 changed: modestas@host1plus.com 20140814 #13:04:53Z source: RADB route: 191.101.0.0/21 descr: Digital Energy Technologies LTD. origin: AS25761 mnt-by: MAINT-AS61440 changed: modestas@host1plus.com 20150610 #08:53:38Z source: RADB —Sandy (Since bgp.he.net changes as the routing world changes, the red keys could be gone by the time anyone looks, of course.)
On Tue, Sep 13, 2016 at 2:51 PM, Mel Beckman <mel@beckman.org <javascript:;>>
wrote:
Blake,
I concur that these are key questions. Probably _the_ key questions. The fabric of the Internet is today based on trust, and BGP's integrity is the core of that trust.
I realize that BGP hijacking is not uncommon. However, this is the first time I've seen in it used defensively. I don't see a way to ever bless this kind of defensive use without compromising that core trust. If Internet reachability depends on individual providers believing that they are justified in violating that trust when they are attacked, how can the Internet stand?
In addition to the question posed to Bryant about whether he would take this action again, I would like to add: what about the innocent parties impacted by your actions? Or do you take the position there were no innocent parties in the hijacked prefixes?
-mel via cell
On Sep 13, 2016, at 11:40 AM, Blake Hudson <blake@ispn.net <javascript:;>> wrote:
Bryant Townsend wrote on 9/13/2016 2:22 AM:
This was the point where I decided I needed to go on the offensive to protect myself, my partner, visiting family, and my employees. The actions proved to be extremely effective, as all forms of harassment and threats from the attackers immediately stopped.
Bryant, what actions, exactly, did you take? This topic seems intentionally glossed over while you spend a much larger amount of time explaining the back story and your motivations rather than your actions.
Questions I was left with:
1. What prefixes have you announced without permission (not just this event)? 2. How did you identify these prefixes? 3. Did you attempt to contact the owner of these prefixes? 4. Did you attempt to contact the origin or transit AS of these prefixes? 5. What was the process to get your upstream AS to accept these prefix announcements? 6. Was your upstream AS complicit in allowing you to announce prefixes you did not have authorization to announce?
-- DougM at Work
On Sep 13, 2016, at 12:22 AM, Bryant Townsend <bryant@backconnect.com> wrote:
*Events that caused us to perform the BGP hijack*: After the DDoS attacks subsided, the attackers started to harass us by calling in using spoofed phone numbers. Curious to what this was all about, we fielded various calls which allowed us to ascertain who was behind the attacks by correlating e-mails with the information they provided over the phone. Throughout the day and late into the night, these calls and threats continued to increase in number. Throughout these calls we noticed an increasing trend of them bringing up personal information of myself and employees. At this point I personally filled a police report in preparation to a possible SWATing attempt. As they continued to harass our company, more and more red flags indicated that I would soon be targeted. This was the point where I decided I needed to go on the offensive to protect myself, my partner, visiting family, and my employees.
I think you're saying that the BGP hijack wasn't done in as part of an attempt to mitigate a DDoS, rather that you used the tools you had available to go on the offensive in response to phone calls you received. Am I reading that right? Cheers, Steve
@ca & Matt - No, we do not plan to ever intentionally perform a non-authorized BGP hijack in the future. @Steve - Correct, the attack had already been mitigated. The decision to hijack the attackers IP space was to deal with their threats, which if carried through could have potentially lead to physical harm. Although the hijack gave us a unique insight into the attackers services, it was not a factor that influenced my decision. @Blake & Mel - We will likely cover some of these questions in a future blog post.
On Tuesday, September 13, 2016, Bryant Townsend <bryant@backconnect.com> wrote:
@ca & Matt - No, we do not plan to ever intentionally perform a non-authorized BGP hijack in the future.
Great answer. Thanks. Committing to pursuing a policy of weaponizing BGP would have triggered a serious "terms of service" violations that would have effectively ended your business swiftly and permanently. Tip to the RIR policy folks, you may want to make this point very crisp. A BGP ASN is the fundamental accountability control in a inter-domain routing. Organizations with repeated offensense need to have their ASN revoked, and further there should be controls in places so bad actors cannot acquire "burner" ASNs. @Steve - Correct, the attack had already been mitigated. The decision to
hijack the attackers IP space was to deal with their threats, which if carried through could have potentially lead to physical harm. Although the hijack gave us a unique insight into the attackers services, it was not a factor that influenced my decision.
@Blake & Mel - We will likely cover some of these questions in a future blog post.
Ca By wrote on 9/13/2016 2:53 PM:
On Tuesday, September 13, 2016, Bryant Townsend <bryant@backconnect.com> wrote:
@ca & Matt - No, we do not plan to ever intentionally perform a non-authorized BGP hijack in the future. Great answer. Thanks.
Committing to pursuing a policy of weaponizing BGP would have triggered a serious "terms of service" violations that would have effectively ended your business swiftly and permanently.
Tip to the RIR policy folks, you may want to make this point very crisp. A BGP ASN is the fundamental accountability control in a inter-domain routing. Organizations with repeated offensense need to have their ASN revoked, and further there should be controls in places so bad actors cannot acquire "burner" ASNs.
@Steve - Correct, the attack had already been mitigated. The decision to hijack the attackers IP space was to deal with their threats, which if carried through could have potentially lead to physical harm. Although the hijack gave us a unique insight into the attackers services, it was not a factor that influenced my decision.
@Blake & Mel - We will likely cover some of these questions in a future blog post.
Ca, and the community, I don't make the leap. How does attacking someone by hijacking their IP space mitigate a physical threat? How does impeding someone's access to the internet access prevent them from performing an act of physical violence against you? If a party threatens me, would I be justified in attacking him or her? In my experience, attacking someone is more likely to escalate a situation - not deescalate it. Bryant did weaponize BGP and stated he stands by his actions and further indicated that he will use what he learned here to shape handling of future situations:
I have spent a long time reflecting on my decision and how it may negatively impact the company and myself in some people’s eyes, but ultimately I stand by it. The experience and feedback I have gained from these events has proven invaluable and will be used to shape the policies surrounding the future handling of similar situations.
When I read Bryant's comments, I see justification and excuses for his behavior. I do not see an apology nor admission of wrongdoing. I believe what Bryant did was wrong and I would hate for others to be allowed to act similarly without consequence.
On 13/09/2016 23:22, Blake Hudson wrote:
Ca By wrote on 9/13/2016 2:53 PM:
On Tuesday, September 13, 2016, Bryant Townsend <bryant@backconnect.com> wrote:
Tip to the RIR policy folks, you may want to make this point very crisp. A BGP ASN is the fundamental accountability control in a inter-domain routing. Organizations with repeated offensense need to have their ASN revoked, and further there should be controls in places so bad actors cannot acquire "burner" ASNs.
The RIRs have made it very clear that they will not get involved. Period. -Hank
So after reading your explanation of things... Your technical protections for your client proved sufficient to handle the attack. You took OFFENSIVE action by hijacking the IP space. By your own statements, it was only in response to threats against your company. You were no longer providing DDoS protection to a client. You were exacting a vendetta against someone who was being MEAN to you. Even if that person probably deserved it, you still cannot do what was done. I appreciate the desire to want to protect friends and family from anonymous threats, and also realize how ill equipped law enforcement usually is while something like this is occurring. However, in my view, by taking the action you did, you have shown your company isn't ready to be operating in the security space. Being threatened by bad actors is a nominal part of doing business in the security space. Unfortunately you didn't handle it well, and I think that will stick to you for a long time. On Tue, Sep 13, 2016 at 3:29 PM, Bryant Townsend <bryant@backconnect.com> wrote:
@ca & Matt - No, we do not plan to ever intentionally perform a non-authorized BGP hijack in the future.
@Steve - Correct, the attack had already been mitigated. The decision to hijack the attackers IP space was to deal with their threats, which if carried through could have potentially lead to physical harm. Although the hijack gave us a unique insight into the attackers services, it was not a factor that influenced my decision.
@Blake & Mel - We will likely cover some of these questions in a future blog post.
Lucy, you got some (*serious*) 'splainin to do... http://research.dyn.com/2016/09/backconnects-suspicious-bgp-hijacks/ http://krebsonsecurity.com/2016/09/ddos-mitigation-firm-has-history-of-hijac... -- Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com pgp key: B178313E | also on Signal On Sun 2016-Sep-18 22:25:44 -0400, Tom Beecher <beecher@beecher.cc> wrote:
So after reading your explanation of things...
Your technical protections for your client proved sufficient to handle the attack. You took OFFENSIVE action by hijacking the IP space. By your own statements, it was only in response to threats against your company. You were no longer providing DDoS protection to a client. You were exacting a vendetta against someone who was being MEAN to you. Even if that person probably deserved it, you still cannot do what was done.
I appreciate the desire to want to protect friends and family from anonymous threats, and also realize how ill equipped law enforcement usually is while something like this is occurring.
However, in my view, by taking the action you did, you have shown your company isn't ready to be operating in the security space. Being threatened by bad actors is a nominal part of doing business in the security space. Unfortunately you didn't handle it well, and I think that will stick to you for a long time.
On Tue, Sep 13, 2016 at 3:29 PM, Bryant Townsend <bryant@backconnect.com> wrote:
@ca & Matt - No, we do not plan to ever intentionally perform a non-authorized BGP hijack in the future.
@Steve - Correct, the attack had already been mitigated. The decision to hijack the attackers IP space was to deal with their threats, which if carried through could have potentially lead to physical harm. Although the hijack gave us a unique insight into the attackers services, it was not a factor that influenced my decision.
@Blake & Mel - We will likely cover some of these questions in a future blog post.
While I was reading the krebsonsecurity.com article cited below, the site, hosted at Akamai address 72.52.7.144, became non responsive and now appears to be offline. Traceroutes stop before the Akamai-SWIPed border within Telia, as if blackholed (but adjacent IPs pass through to Akamai): traceroute to krebsonsecurity.com (72.52.7.144), 64 hops max, 40 byte packets 1 router1.sb.becknet.com (206.83.0.1) 0.771 ms 0.580 ms 0.342 ms 2 206-190-77-9.static.twtelecom.net (206.190.77.9) 0.715 ms 1.026 ms 0.744 ms 3 ae1-90g.ar7.lax1.gblx.net (67.17.75.18) 9.532 ms 6.567 ms 2.912 ms 4 ae10.edge1.losangeles9.level3.net (4.68.111.21) 2.919 ms 2.925 ms 2.904 ms 5 telia-level3-4x10g.losangeles.level3.net (4.68.70.130) 3.981 ms 3.567 ms 3.401 ms 6 sjo-b21-link.telia.net (62.115.116.40) 11.209 ms 11.140 ms 11.161 ms 7 * * * 8 * * * 9 * * * 10 * * * Weird coincidence? -mel beckman
On Sep 20, 2016, at 6:46 PM, Hugo Slabbert <hugo@slabnet.com> wrote:
Lucy, you got some (*serious*) 'splainin to do...
http://research.dyn.com/2016/09/backconnects-suspicious-bgp-hijacks/ http://krebsonsecurity.com/2016/09/ddos-mitigation-firm-has-history-of-hijac...
-- Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com pgp key: B178313E | also on Signal
On Sun 2016-Sep-18 22:25:44 -0400, Tom Beecher <beecher@beecher.cc> wrote:
So after reading your explanation of things...
Your technical protections for your client proved sufficient to handle the attack. You took OFFENSIVE action by hijacking the IP space. By your own statements, it was only in response to threats against your company. You were no longer providing DDoS protection to a client. You were exacting a vendetta against someone who was being MEAN to you. Even if that person probably deserved it, you still cannot do what was done.
I appreciate the desire to want to protect friends and family from anonymous threats, and also realize how ill equipped law enforcement usually is while something like this is occurring.
However, in my view, by taking the action you did, you have shown your company isn't ready to be operating in the security space. Being threatened by bad actors is a nominal part of doing business in the security space. Unfortunately you didn't handle it well, and I think that will stick to you for a long time.
On Tue, Sep 13, 2016 at 3:29 PM, Bryant Townsend <bryant@backconnect.com> wrote:
@ca & Matt - No, we do not plan to ever intentionally perform a non-authorized BGP hijack in the future.
@Steve - Correct, the attack had already been mitigated. The decision to hijack the attackers IP space was to deal with their threats, which if carried through could have potentially lead to physical harm. Although the hijack gave us a unique insight into the attackers services, it was not a factor that influenced my decision.
@Blake & Mel - We will likely cover some of these questions in a future blog post.
earlier on Twitter Krebs said he was hit by 665Gbps attack (so says Prolexic/Akamai). Could be ongoing/related. ____________ Justin Paine Head of Trust & Safety CloudFlare Inc. PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D On Tue, Sep 20, 2016 at 8:21 PM, Mel Beckman <mel@beckman.org> wrote:
While I was reading the krebsonsecurity.com article cited below, the site, hosted at Akamai address 72.52.7.144, became non responsive and now appears to be offline. Traceroutes stop before the Akamai-SWIPed border within Telia, as if blackholed (but adjacent IPs pass through to Akamai):
traceroute to krebsonsecurity.com (72.52.7.144), 64 hops max, 40 byte packets 1 router1.sb.becknet.com (206.83.0.1) 0.771 ms 0.580 ms 0.342 ms 2 206-190-77-9.static.twtelecom.net (206.190.77.9) 0.715 ms 1.026 ms 0.744 ms 3 ae1-90g.ar7.lax1.gblx.net (67.17.75.18) 9.532 ms 6.567 ms 2.912 ms 4 ae10.edge1.losangeles9.level3.net (4.68.111.21) 2.919 ms 2.925 ms 2.904 ms 5 telia-level3-4x10g.losangeles.level3.net (4.68.70.130) 3.981 ms 3.567 ms 3.401 ms 6 sjo-b21-link.telia.net (62.115.116.40) 11.209 ms 11.140 ms 11.161 ms 7 * * * 8 * * * 9 * * * 10 * * *
Weird coincidence?
-mel beckman
On Sep 20, 2016, at 6:46 PM, Hugo Slabbert <hugo@slabnet.com> wrote:
Lucy, you got some (*serious*) 'splainin to do...
http://research.dyn.com/2016/09/backconnects-suspicious-bgp-hijacks/ http://krebsonsecurity.com/2016/09/ddos-mitigation-firm-has-history-of-hijac...
-- Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com pgp key: B178313E | also on Signal
On Sun 2016-Sep-18 22:25:44 -0400, Tom Beecher <beecher@beecher.cc> wrote:
So after reading your explanation of things...
Your technical protections for your client proved sufficient to handle the attack. You took OFFENSIVE action by hijacking the IP space. By your own statements, it was only in response to threats against your company. You were no longer providing DDoS protection to a client. You were exacting a vendetta against someone who was being MEAN to you. Even if that person probably deserved it, you still cannot do what was done.
I appreciate the desire to want to protect friends and family from anonymous threats, and also realize how ill equipped law enforcement usually is while something like this is occurring.
However, in my view, by taking the action you did, you have shown your company isn't ready to be operating in the security space. Being threatened by bad actors is a nominal part of doing business in the security space. Unfortunately you didn't handle it well, and I think that will stick to you for a long time.
On Tue, Sep 13, 2016 at 3:29 PM, Bryant Townsend <bryant@backconnect.com> wrote:
@ca & Matt - No, we do not plan to ever intentionally perform a non-authorized BGP hijack in the future.
@Steve - Correct, the attack had already been mitigated. The decision to hijack the attackers IP space was to deal with their threats, which if carried through could have potentially lead to physical harm. Although the hijack gave us a unique insight into the attackers services, it was not a factor that influenced my decision.
@Blake & Mel - We will likely cover some of these questions in a future blog post.
Brian Krebs tweeted out that Prolexic reported a 665Gbps attack directed at his site. https://twitter.com/briankrebs/status/778398865619836928 On Tue, Sep 20, 2016 at 11:21 PM, Mel Beckman <mel@beckman.org> wrote:
While I was reading the krebsonsecurity.com article cited below, the site, hosted at Akamai address 72.52.7.144, became non responsive and now appears to be offline. Traceroutes stop before the Akamai-SWIPed border within Telia, as if blackholed (but adjacent IPs pass through to Akamai):
traceroute to krebsonsecurity.com (72.52.7.144), 64 hops max, 40 byte packets 1 router1.sb.becknet.com (206.83.0.1) 0.771 ms 0.580 ms 0.342 ms 2 206-190-77-9.static.twtelecom.net (206.190.77.9) 0.715 ms 1.026 ms 0.744 ms 3 ae1-90g.ar7.lax1.gblx.net (67.17.75.18) 9.532 ms 6.567 ms 2.912 ms 4 ae10.edge1.losangeles9.level3.net (4.68.111.21) 2.919 ms 2.925 ms 2.904 ms 5 telia-level3-4x10g.losangeles.level3.net (4.68.70.130) 3.981 ms 3.567 ms 3.401 ms 6 sjo-b21-link.telia.net (62.115.116.40) 11.209 ms 11.140 ms 11.161 ms 7 * * * 8 * * * 9 * * * 10 * * *
Weird coincidence?
-mel beckman
On Sep 20, 2016, at 6:46 PM, Hugo Slabbert <hugo@slabnet.com> wrote:
Lucy, you got some (*serious*) 'splainin to do...
http://research.dyn.com/2016/09/backconnects-suspicious-bgp-hijacks/ http://krebsonsecurity.com/2016/09/ddos-mitigation-firm- has-history-of-hijacks/
-- Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com pgp key: B178313E | also on Signal
On Sun 2016-Sep-18 22:25:44 -0400, Tom Beecher <beecher@beecher.cc> wrote:
So after reading your explanation of things...
Your technical protections for your client proved sufficient to handle the attack. You took OFFENSIVE action by hijacking the IP space. By your own statements, it was only in response to threats against your company. You were no longer providing DDoS protection to a client. You were exacting a vendetta against someone who was being MEAN to you. Even if that person probably deserved it, you still cannot do what was done.
I appreciate the desire to want to protect friends and family from anonymous threats, and also realize how ill equipped law enforcement usually is while something like this is occurring.
However, in my view, by taking the action you did, you have shown your company isn't ready to be operating in the security space. Being threatened by bad actors is a nominal part of doing business in the security space. Unfortunately you didn't handle it well, and I think that will stick to you for a long time.
On Tue, Sep 13, 2016 at 3:29 PM, Bryant Townsend < bryant@backconnect.com> wrote:
@ca & Matt - No, we do not plan to ever intentionally perform a non-authorized BGP hijack in the future.
@Steve - Correct, the attack had already been mitigated. The decision to hijack the attackers IP space was to deal with their threats, which if carried through could have potentially lead to physical harm. Although the hijack gave us a unique insight into the attackers services, it was not a factor that influenced my decision.
@Blake & Mel - We will likely cover some of these questions in a future blog post.
Hello, We wanted to clarify that we are not the ones behind these attacks and we were not the ones behind the previous hijackings. We have also been the targets of DDoS attacks reaching up to 200+ Gbps (~20 times a day), every day since Krebs' original article that included our name. We believe these attacks are coming from vDOS past customers and other botnets that used the vDOS service for launching and selling attacks. We have also been targeted with what seems to be multiple e-mail list bombs in attempts to delay our response time. As I mentioned before, NANOG's trust means everything in this industry and we want to be able to answer as much as we can. Sincerely, Bryant Townsend On Tue, Sep 20, 2016 at 8:28 PM, Tom Beecher <beecher@beecher.cc> wrote:
Brian Krebs tweeted out that Prolexic reported a 665Gbps attack directed at his site.
https://twitter.com/briankrebs/status/778398865619836928
On Tue, Sep 20, 2016 at 11:21 PM, Mel Beckman <mel@beckman.org> wrote:
While I was reading the krebsonsecurity.com article cited below, the site, hosted at Akamai address 72.52.7.144, became non responsive and now appears to be offline. Traceroutes stop before the Akamai-SWIPed border within Telia, as if blackholed (but adjacent IPs pass through to Akamai):
traceroute to krebsonsecurity.com (72.52.7.144), 64 hops max, 40 byte packets 1 router1.sb.becknet.com (206.83.0.1) 0.771 ms 0.580 ms 0.342 ms 2 206-190-77-9.static.twtelecom.net (206.190.77.9) 0.715 ms 1.026 ms 0.744 ms 3 ae1-90g.ar7.lax1.gblx.net (67.17.75.18) 9.532 ms 6.567 ms 2.912 ms 4 ae10.edge1.losangeles9.level3.net (4.68.111.21) 2.919 ms 2.925 ms 2.904 ms 5 telia-level3-4x10g.losangeles.level3.net (4.68.70.130) 3.981 ms 3.567 ms 3.401 ms 6 sjo-b21-link.telia.net (62.115.116.40) 11.209 ms 11.140 ms 11.161 ms 7 * * * 8 * * * 9 * * * 10 * * *
Weird coincidence?
-mel beckman
On Sep 20, 2016, at 6:46 PM, Hugo Slabbert <hugo@slabnet.com> wrote:
Lucy, you got some (*serious*) 'splainin to do...
http://research.dyn.com/2016/09/backconnects-suspicious-bgp-hijacks/ http://krebsonsecurity.com/2016/09/ddos-mitigation-firm- has-history-of-hijacks/
-- Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com pgp key: B178313E | also on Signal
On Sun 2016-Sep-18 22:25:44 -0400, Tom Beecher <beecher@beecher.cc> wrote:
So after reading your explanation of things...
Your technical protections for your client proved sufficient to handle the attack. You took OFFENSIVE action by hijacking the IP space. By your own statements, it was only in response to threats against your company. You were no longer providing DDoS protection to a client. You were exacting a vendetta against someone who was being MEAN to you. Even if that person probably deserved it, you still cannot do what was done.
I appreciate the desire to want to protect friends and family from anonymous threats, and also realize how ill equipped law enforcement usually is while something like this is occurring.
However, in my view, by taking the action you did, you have shown your company isn't ready to be operating in the security space. Being threatened by bad actors is a nominal part of doing business in the security space. Unfortunately you didn't handle it well, and I think that will stick to you for a long time.
On Tue, Sep 13, 2016 at 3:29 PM, Bryant Townsend < bryant@backconnect.com> wrote:
@ca & Matt - No, we do not plan to ever intentionally perform a non-authorized BGP hijack in the future.
@Steve - Correct, the attack had already been mitigated. The decision to hijack the attackers IP space was to deal with their threats, which if carried through could have potentially lead to physical harm. Although the hijack gave us a unique insight into the attackers services, it was not a factor that influenced my decision.
@Blake & Mel - We will likely cover some of these questions in a future blog post.
On Tue, Sep 13, 2016 at 10:25 AM Bryant Townsend <bryant@backconnect.com> wrote:
I also wanted to let Hugo (who started the thread) know that we harbor no hard feelings about bringing this topic up, as it is relevant to the community and does warrant discussion. Hugo, you may owe me a beer the next time we meet. :)
Wait, so if I hijack someone else's prefix, someone ends up buying me a beer? Let me fire up my terminal...
participants (14)
-
Blake Hudson -
Bryant Townsend -
Ca By -
Doug Montgomery -
Hank Nussbacher -
Hugo Slabbert -
Hunter Fuller -
Justin Paine -
Matt Freitag -
Mel Beckman -
Ryan, Spencer -
Sandra Murphy -
Steve Atkins -
Tom Beecher