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 which are launched from infected, violated, and penetrated devices on the Internet. There “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 sends packets with a “spoofed” source address to a device which will “reflect” that attack. The “spoof” includes the IP address of the targeted network. When the “3rd party” receives the spoofed packet, it will replace to the source – which is the target, not the device which originally sent the packet. This allows the attacker to whack the target with a DoS attack without giving away their location.
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 which 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 their customer edge of their network to ensure that approved customers IPv4 and IPv6 source addresses are allowed.
There is a range of techniques to deploy anti-spoof BCP 38 filtering (see http://www.bcp38.info/). The 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 re-born Spoofer Project presented their first view 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 September 2, 2016. The session, Software Systems for Surveying Spoofing Susceptibility, updated the community of the Spoofer Tool and the new reports available to the whole Internet Community.
The Spoofer Client
The Spoofer Project provides a client that anyone can download to their computer to run “spoof test” on their network. It can be set up to wake up and test any network the computer connects. This ability allows anyone to see if their connected network allows spoofed packets as their 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, public data on which ASNs (networks) and which Countries are contributing to the Spoofed DoS attacks.
(Download your copy from https://www.caida.org/projects/spoofer/)
Reporting on Network Which Contributed to Spoofed DoS Attacks
Transparent reporting of who is doing on what on the Internet is a tradition. The Spoofer Project is continuing on with this transparency with a reporting tool that allows anyone to search based on the Autonomous System Number (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 on their upstream service provider is allowing spoofed addresses, then 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 which they connect to see if which networks are “naughty spoofers” and which are “nice BCP compliant networks.”
(see https://spoofer.caida.org/recent_tests.php)
CxOs – What should you do?
If you are a CxO in an organization, 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. That would have your staff’s computer 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 for any attempts at “spoofing.” If 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 is 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 Providers (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 which 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 Center. Devices in a data center will get targeted and “owned” my threat actors from all over the world. These threat actors would then use these “violated devices” to launch spoofed attacks out from the data center to targets throughout the world. Given this, the CxO should be asking their data center team what they do to prevent spoof packets from leaving the data center. If there is no anti-spoofing, then demand a plan. Again, the BCP-38 “anti-spoofing” tools are not hard are most likely built into the equipment already deployed in the data center.
- Check on your Cloud Networks. Cloud networks are no different from data center 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 they 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 deploy which “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.
≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣≣
➥ Barry Greene is Business Development Executive ★ Internet Technologist ★ 25 Year Veteran of Internet Security ★ Emerging Technology Mentor ★ Advisor to Innovative Startups ★ ‘Internet in Asia’ Expert
➥ Barry connects to peers, colleagues and aspiring talent via Linkedin (www.linkedin.com/in/barryrgreene/). You can also follow on Barry on Twitter (@BarryRGreene) or his blogs on Senki (www.senki.org).