Cyber attack downs Telstra network, affecting thousands of internet users
A cyber attack has brought down the internet address book that runs Telstra's network, resulting in thousands of people in Sydney and Melbourne reporting outages on Sunday morning.
The telco tweeted that it was looking into an issue impacting home internet connections, including those on the NBN. There were also reports from users that phones were affected too.
"We've identified the issue and are working on it," the telco later said. "Some of our Domain Name Servers (DNS) used to route your traffic online are experiencing a cyber attack, known as a Denial of Service (DoS). Your info isn't at risk. We're doing all we can to get you back online."
https://www.smh.com.au/national/nsw/thousands-affected-by-telstra-internet-outage-20200802-p55hq9.html
#australia #telstra #DoS #telecom
A cyber attack has brought down the internet address book that runs Telstra's network, resulting in thousands of people in Sydney and Melbourne reporting outages on Sunday morning.
The telco tweeted that it was looking into an issue impacting home internet connections, including those on the NBN. There were also reports from users that phones were affected too.
"We've identified the issue and are working on it," the telco later said. "Some of our Domain Name Servers (DNS) used to route your traffic online are experiencing a cyber attack, known as a Denial of Service (DoS). Your info isn't at risk. We're doing all we can to get you back online."
https://www.smh.com.au/national/nsw/thousands-affected-by-telstra-internet-outage-20200802-p55hq9.html
#australia #telstra #DoS #telecom
Forwarded from BlackBox (Security) Archiv
How to stop the onion denial (of service)
As you might have heard, some onion services have been experiencing issues with denial-of-service (DoS) attacks over the past few years.
The attacks exploit the inherent asymmetric nature of the onion service rendezvous protocol, and that makes it a hard problem to defend against. During the rendezvous protocol, an evil client can send a small message to the service while the service has to do lots of expensive work to react to it. This asymmetry opens the protocol to DoS attacks, and the anonymous nature of our network makes it extremely challenging to filter the good clients from the bad.
For the past two years, we've been providing more scaling options to onion service operators, supporting more agile circuit management and protecting the network and the service host from CPU exhaustion. While these don't fix the root problem, they provide a framework to onion service operators to build their own DoS detection and handling infrastructure.
Even though the toolbox of available defenses for onion service operators has grown, the threat of DoS attacks still looms large. And while there is still a bunch of smaller-scale improvements that could be done, we believe that this is not the kind of problem that a parameter tweak or small code change will make it disappear. The inherent nature of the problem makes us believe that we need to make fundamental changes to address it.
In this post, we would like to present you with two options that we believe can provide a long-term defense to the problem while maintaining the usability and security of onion services.
The intuition to keep in mind when considering these designs is that we need to be able to offer different notions of fairness. In today's onion services, each connection request is indistinguishable from all the other requests (it's an anonymity system after all), so the only available fairness strategy is to treat each request equally -- which means that somebody who makes more requests will inherently get more attention.
The alternatives we describe here use two principles to change the balance: (1) the client should have the option to include some new information in its request, which the onion service can use to more intelligently prioritize which requests it answers; and (2) rather than a static requirement in place at all times, we should let onion services scale the defenses based on current load, with the default being to answer everything.
👀 👉🏼 https://blog.torproject.org/stop-the-onion-denial
#tor #onion #DoS #attack
📡@cRyPtHoN_INFOSEC_DE
📡@cRyPtHoN_INFOSEC_EN
📡@BlackBox_Archiv
📡@NoGoolag
As you might have heard, some onion services have been experiencing issues with denial-of-service (DoS) attacks over the past few years.
The attacks exploit the inherent asymmetric nature of the onion service rendezvous protocol, and that makes it a hard problem to defend against. During the rendezvous protocol, an evil client can send a small message to the service while the service has to do lots of expensive work to react to it. This asymmetry opens the protocol to DoS attacks, and the anonymous nature of our network makes it extremely challenging to filter the good clients from the bad.
For the past two years, we've been providing more scaling options to onion service operators, supporting more agile circuit management and protecting the network and the service host from CPU exhaustion. While these don't fix the root problem, they provide a framework to onion service operators to build their own DoS detection and handling infrastructure.
Even though the toolbox of available defenses for onion service operators has grown, the threat of DoS attacks still looms large. And while there is still a bunch of smaller-scale improvements that could be done, we believe that this is not the kind of problem that a parameter tweak or small code change will make it disappear. The inherent nature of the problem makes us believe that we need to make fundamental changes to address it.
In this post, we would like to present you with two options that we believe can provide a long-term defense to the problem while maintaining the usability and security of onion services.
The intuition to keep in mind when considering these designs is that we need to be able to offer different notions of fairness. In today's onion services, each connection request is indistinguishable from all the other requests (it's an anonymity system after all), so the only available fairness strategy is to treat each request equally -- which means that somebody who makes more requests will inherently get more attention.
The alternatives we describe here use two principles to change the balance: (1) the client should have the option to include some new information in its request, which the onion service can use to more intelligently prioritize which requests it answers; and (2) rather than a static requirement in place at all times, we should let onion services scale the defenses based on current load, with the default being to answer everything.
👀 👉🏼 https://blog.torproject.org/stop-the-onion-denial
#tor #onion #DoS #attack
📡@cRyPtHoN_INFOSEC_DE
📡@cRyPtHoN_INFOSEC_EN
📡@BlackBox_Archiv
📡@NoGoolag
blog.torproject.org
How to stop the onion denial (of service) | Tor Project
As you might have heard, some onion services have been experiencing issues with denial-of-service (DoS) attacks over the past few years. In this post, we would like to present you with two options that we believe can provide a long-term defense to the problem…