Are you part of the DDoS problem?

By on 13 Sep 2016

Category: Tech matters

Tags: , ,

1 Comment

Blog home

Yes, your network, your service provider, and your government can be actively contributing to the global Denial of Service (DoS) epidemic!

DoS attacks come in two ‘families’. The first DoS family are from tools that are launched from infected, violated, and penetrated devices on the Internet. They’re ‘remote controlled’ by the attackers to hit a target. The industry can trace back to the source of the attack and remediate these violated devices.

The second DoS family attack are ‘spoofed attacks’. Spoofed DoS attacks send packets with a ‘spoofed’ source address to a device that will ‘reflect’ that attack. The ‘spoof’ includes the IP address of the targeted network. When the ‘third party’ receives the spoofed packet, it will replace to the source – which is the target, not the device that originally sent the packet. This allows the attacker to whack the target with a DoS attack without giving away their location.

BarryGreene_DDOSimage_1

What does an attacker need to launch a spoofed DoS attack? Simple, an enterprise, service provider or institution, which allows for spoofed packets to leave their network.

It is well known that the industry Best Common Practice (BCP) for all networks is to not allow spoofed addresses to leave their network into the Internet. This is commonly known as BCP 38.

There are a range of activities that actively teach these ‘anti-spoofing’ BCPs. The Internet Society’s Mutually Agreed Norms for Routing Security (MANRS) (see RoutingManifesto.org) is one of the latest and a good place to start. But, as a review, MANRS expects:

  • Enterprise Networks connected to the Internet to filter outbound packets so that only addresses with their allocated IPv4 and IPv6 source addresses are allowed.
  • University Networks connected to the Internet to filter outbound packets so that only addresses with their allocated IPv4 and IPv6 source addresses are allowed.
  • Service Provider Networks filter on the customer edge of their network to ensure that only approved customers’ IPv4 and IPv6 source addresses are allowed.

There are a range of techniques to deploy anti-spoof BCP 38 filtering (see http://www.bcp38.info/). Anti-spoofing techniques are not hard. They are not a major burden on the hardware. Most are critical to monitor the security of an enterprise. Yet, networks choose to contribute to the global DoS attack problem by not deploying this simple Internet hygiene. This will change.

The Spoofer Project – measuring the impact

The reborn Spoofer Project presented their first view on how the industry will be measuring which networks are ‘naughty’, and which networks are ‘nice’. Matthew Luckie – a key member of the CAIDA Spoofer Project Team – presented at AusNOG on 2 September 2016.  The session, Software Systems for Surveying Spoofing Susceptibility, updated the community on the Spoofer Tool and the new reports available to the whole Internet community.

The Spoofer Client

<a href="https://www.caida.org/projects/spoofer" target="_blank">Download your copy of Spoofer Tool</a>

The Spoofer Project provides a client that anyone can download to their computer to run a ‘spoof test’ on their network. It can be set up to wake up and test any network the computer connects with. This ability allows anyone to see if their connected network allows spoofed packets as they move from different WiFi, LTE, home, and enterprise networks.

The more people who download and use the Spoofer Tool, the better for everyone on the Internet. It facilitates the next Spoofer Project update, and provides public data on which Autonomous System Numbers (ASNs) (networks) and countries are contributing to the spoofed DoS attacks.

Reporting on networks that contributed to spoofed DoS attacks

A <a href="https://spoofer.caida.org/recent_tests.php" target="_blank">recent test</a> ran on Spoofer Project

Transparent reporting of who is doing what on the Internet is a tradition. The Spoofer Project is continuing with this transparency with a reporting tool that allows anyone to search based on the ASN and the country.

This level of reporting will allow one organization to check on another organization. For example, if a bank wishes to check that their upstream service provider is allowing spoofed addresses, they can use the Spoofer Project’s tool by searching on the ASN. If an insurance company is checking on the bank to see if they are allowing spoofed IP addresses, they can use the ASN to search on the results.

In other words, as more volunteers install the Spoofer Client, the more people can check on the networks with which they connect to see which networks are ‘naughty spoofers’ and which are ‘nice BCP compliant networks.’

CxOs – What should you do?

If you are a CxO, use the following action plan to see if your organization is part of the problem:

  • Install the Spoofer Client. Have people in your organization download and use the Spoofer Client. This will help with testing your networks, all the WiFi systems around your office, your mobile operator’s 3G/4G network, other ‘partner’ organizations, and your staff’s home networks.
  • Ask your team for the ‘Anti-Spoofing Plan.’ Ask your network team what tools are used to ensure that no spoofed packet leaves your networks. In many situations, these anti-spoof tools would also monitor any attempts at spoofing – it could be an indication of ‘miscreant activity’ inside the network. If there are no tools in place to prevent spoofed packets, then ask the network team to deliver an anti-spoofing plan of action. As mentioned, there are a range of tools that work.
  • Check on your upstream service provider networks. If you are an enterprise connected to the Internet, it is reasonable to expect your upstream Internet Service Provider (ISPs) to deploy anti-spoofing techniques throughout their network. Start with asking the ISP’s account manager to present to your team their anti-spoof strategy. During this meeting, both parties can access the Spoofer Projects reports on their network by searching for the ASN (see https://spoofer.caida.org/recent_tests.php). ISPs that allow for spoofed traffic are contributing to the global DoS attack problem. The CxO should then question if the additional risk is worth any discounts.
  • Check your corporate data centre. Devices in a data centre will get targeted and ‘owned’ by threat actors from all over the world. These threat actors would then use these ‘violated devices’ to launch spoofed attacks out from the data centre to targets throughout the world. Given this, the CxO should be asking their data centre team what they do to prevent spoof packets from leaving the data centre. If there is no anti-spoofing, then demand a plan. Again, the BCP 38 anti-spoofing tools are not hard and are most likely built into the equipment already deployed in the data centre.
  • Check on your cloud networks. Cloud networks are no different from data centre networks. Threat actors from all parts of the world will find ways to break into the virtual resources in your cloud deployments, violate those instances with their malware, and see if they can launch spoofed attacks from these cloud resources. The CxO must ask their cloud team for the anti-spoofing plan. Some of this might be the enterprise’s configuration. Other parts might be built into the cloud operator’s deployments.

Use the Spoofer Client to audit your ‘Anti-Spoofing’

‘Operational Entropy’ is the term we use to describe policies deployed that ‘decay’ as they are neglected. In the case of anti-spoofing tools, it is often the case where a network team deploys the tools, they work great for a year, but over time have spoofing holes created as the network naturally evolves. This operational entropy is normal for a network. This is why checks are required to ensure the policies remain effective. The Spoofer Client is a cost-effective approach to keeping an eye on anti-spoofing entropy in your network.

Original post appeared on LinkedIn.

Barry Greene is a is 25-year veteran of Internet security.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Please answer the math question * Time limit is exhausted. Please reload CAPTCHA.

Top