Chapter 5. DDoS Focused Threat Intelligence
Threat intelligence has received a lot of attention lately. In today’s world, almost all companies rely on digitized information. Show us a company that does not have valuable assets in digital form and we will show you a company that is not competitive in its own market. Digital assets are easy to move around and store, but also easy to be stolen and compromised. Security threat intelligence is a term that describes the collection of data that might be a threat to your valuable digital assets.
According to Gartner, the definition of threat intelligence is as follows:
Threat Intelligence is evidence-based knowledge, including context, mechanisms, indicators, implications and actionable advice, about an existing or emerging menace or hazard to assets that can be used to inform decisions regarding the subject’s response to that menace or hazard.
If applied to the context of DDoS threat intelligence, we can conclude that the results should be data-driven, evidence-based, and include analysis of data about existing or emerging DDoS threats and actionable responses.
In this chapter, we will discuss the collection of data that will reveal potential DDoS security threats and show you ways to store and analyze the data. From there, we can derive response that can help you prevent and defend against future DDoS attacks.
DDoS Focused Threat Intelligence
Threat intelligence is a much written-about subject, but the relevance of the topic to DDoS is a bit fuzzy. In this chapter, we want to focus on how to collect relevant data that can be applied in DDoS mitigation.
This is a very exciting chapter for us, as we feel this is a way to turn the table on the attackers. So far in the book, we have been in a reactive mode where we are at the receiving end of DDoS attacks. Anybody who has played competitive sports knows if you only play defense, the best result you can hope for is a 0 to 0 draw; it is only when you start to play offense that you can score points and win the game. In discussing threat intelligence, we are going on the offense to actively collect data, set traps for the bad guys, and try to give ourselves advance warnings.
Let’s get started!
IP Blocklists
The first task is to understand the difference between a known bad source IP and source IP addresses which can be a potential attacker. This is an important distinction as you will handle them differently with the policy that you create. These known bad source IP addresses should be the basis for your blacklist. “Known bad” implies that there has been some level of vetting from the security community.
By building your own threat intelligence based IP blocklist you can reduce the size of your attack surface while keeping known bad endpoints from stealing your data. Reducing the number of IP addresses that you need to check increases the effectiveness of both your DDoS detection and mitigation systems. The IP blocklist should include the BOGON IP address ranges that have not been allocated or allocated only for private use, as mentioned in the mitigation chapter. If you see sources from the BOGON list coming to your network, there is a good chance that they are spoofed IPs.
Know Your Customer Source
It would make your life easier as a DDoS protector to know the approximate source of your customer in advance. The geolocation IP correlation is never perfect, but it provides a good baseline. For example, it would be a red flag to see a sudden surge of IP sources from Russia if the majority of your customer base is in North America and Western Europe.
A free GeoIP database is the MaxMind database.
In Figure 5-1, we captured the incoming packets’ source IP addresses at our edge while conducted a UDP flood attack using a DDoS for Hire system. In this particular attack, the BOGON list made up around 15% of the source IPs.
Figure 5-1. Incoming packets at edge in the 0.0.0.0/8 range
Please keep in mind that this or any IP blocklist is dynamic and evolving. You can start with a prebuilt list, such as from Team Cymru, but the most effective blocklist is the one that you build for your context. The work at Team Cymru is one example of community-based efforts for DDoS mitigation.
Community Supported Efforts
A typical engineer’s day is full of interrupt-driven tasks; keeping the lights on is a full-time job. Wouldn’t it be great if there were community-based efforts that could help with DDoS mitigation? Yes, apparently a lot of people have the same idea. In this section, we will look at some of the projects that can help us in DDoS mitigation.
IP Geolocation Providers
We have mentioned IP geolocation a few times so far in the book. Though an IP geolocation provider is not a direct security-related service, it is one of the most important tools that we can use to limit our exposure to provide physical location context to the information we have gathered through various channels. If your business does not serve a particular geography then why let the traffic into your network? This is one way to help reduce your attack surface even further. This will be explored in more detail later in the chapter. While not perfect, they continue to evolve and improve over time.
MaxMind is one such provider with free and paid geolocation databases using simple APIs (Figure 5-2).
Figure 5-2. MaxMind GeoIP products (source: http://bit.ly/2BLheIa)
Purpose-Built Node Lists
As we have stressed in this chapter, knowing your customer sources and blocking unnecessary incoming traffic before it reaches your network border can be a very useful step in protection. Unlike the BOGON list we covered earlier, these lists need to be used with your domain knowledge in order to limit the collateral damage that you might experience if you accidentally block too broad of a scope. We picked out a few of the resources and provide brief reasons for why the list might be useful to you.
The United States State Department maintains a Trade Embargo List. This is an example of a business logic tie-in with technology. If your business is registered in the United States and unable to do business with countries on the list, why even allow the IP prefixes associated with the country inbound? It may make sense to reduce the size of your policy by blocking organizations themselves denoted by autonomous system number in network language. The IP-to-ASN list can be obtained from various sources, including MaxMind. Of course, your situation might be different; we use the US Trade Embargo List as an example to illustrate our point.
The public cloud providers IP list, such as IP addresses owned by Amazon AWS and Microsoft Azure, might be sources you can potentially add to your blocklist. For example, if you only operate an interactive online gaming site, how many of your users come from the public cloud? The answer is probably very few. Even if you utilize the public cloud for operational resources, you can always “explicit permit, implicit deny” when it comes to the IP space.
While TOR exit nodes are not generally involved in a volumetric DDoS attack, they are seen in a number of slow and low attacks. TOR or The Onion Router is an encrypted overlay used to hide the actual source address of the requester. This clearly does not mean they are doing bad things; however, these addresses are easily grouped for policy enforcement, such as session limiting.
There are also a few crowdsourced lists containing systems that have been accused of nefarious activities such as spamming, hijacks, housing malware, and others. The reputation of these networks and hosts is reduced. In Figure 5-3, we see a screenshot from NetLab 360 showing 24 hours of scanning behavior from their observation points.
Figure 5-3. NetLab 360 network scan mon (source: http://bit.ly/2FCQgVN)
The information can be correlated back to the top source IP (Figure 5-4).
Figure 5-4. NetLab 360 network scan mon top SrcIP (source: http://bit.ly/2BJQ18I)
The Spamhaus Drop List contains a list of IP addresses and ASNs that are defunct and hijacked for criminal purposes. EmergingThreats contains a list of IPs of various botnet command and control centers, scanners, and unsolicited traffic.
Real bots are still widely used in DDoS attacks, now even more than ever. In the beginning, botnets were mostly constructed with infected hosts. Think of your coworker who opened an email attachment that was executed as a Trojan horse, and the program in turn opened up a backdoor for someone else to control the computer. This is an example of a more traditional bot. With the rise of internet connected everything, the making of botnets is evolving as well. A bot can now be an IP camera or temperature sensor that was purchase by somebody who never changed the default username and password.
A good example is the Mirai botnet which was used in a high profile DDoS attack that took down a large chunk of the internet in October 2016. It consisted of internet connected cameras, home routers, DVRs, and printers with default credentials used for their telnet ports. This was not an infection—just poor security policy and lack of attention by the vendors. The situation is further complicated by devices with public IPs reachable from the outside world.
In Figure 5-5, you can see an example of result of internet scanning of Mirai-infected hosts.
Figure 5-5. Geolocation of a sample of Mirai-infected devices (source: http://bit.ly/2BJzPo6)
One of the ways that security professionals create their own intelligence about botnets such as Mirai is through actively scanning the internet. While it is tempting to perform some of this scanning on your own it is best to rely on the professionals. Problems can arise such as ISP terms of service violations and reactive black listing of your IP address.
Knowing the IP addresses of infected hosts is a good step in narrowing down potential attack sources. Any list of IP addresses that belong to a botnet is dynamic due to many factors in the Internet. Adding this information to the drop list is not recommended for this reason, however it is very useful to keep as a list of potential suspects which you can apply policy to once an attack has been detected.
Honeypots
A honeypot, in the context of cybersecurity, is a way to attract potential hackers in order to understand them. Placed in various locations of the internet, honeypots can mask themselves as vulnerable hosts and trap potential hackers. We can then use the insights we gain from the interaction to combat and mitigate future DDoS attacks, or better yet, prevent future attacks altogether. If you do decide to deploy honeypots, be careful to separate your production network from the honeypot network to decrease the risk of the dirty traffic bleeding into your production network.
Honeypots as Additional Signal Data
Please keep in mind that the data you collect from honeypots are not reliable and potentially contain false information. They can be used as additional signals after you clean them up and provide more structures to the original data. The challenge will always be to clean the data enough to make intelligent decisions about it.
Our primary use case for a honeypot, when DDoS-focused, is to gain a deeper understanding of the internet-scanning behavior by DDoS-capable botnets. They are also useful to detect the testing of your defenses by attackers before they attack. Since the honeypot can interact with client devices, we are able to see scanners looking for potential bots or source connection attempts, successful logins, and executing commands. Keep in mind that telling the difference between a security researcher and nefarious activity is not straightforward. Analyze this data further before adding to it to your blocklist.
An example of a honeypot project is the Cowrie Honeypot. The project was started by security researcher Michel Oosterhof and derived from the Kippo honeypot project. It is a medium-interaction SSH and Telnet honeypot designed to log brute force attacks and the shell interaction performed by the attacker. Cowrie is not perfect, as it has been fingerprinted but fortunately, from our research, most nefarious sources do not seem to care. Cowrie could be a logical place to start your honeypot effort before moving to more specialized honeypots targeting XML or HTTP specifically.
By combining and containerizing various honeypots, along with the ELK stack, the T-Pot Project provides an easy-to-install, all-in-one host that you can use on your premises to detect potential attacks and hackers. In Figure 5-6, we can glean a lot of information from simply putting a T-Pot host on a public VM, and look like a security superhero to management by making some very simple ELK modifications. Top source IPs, origin countries, destination ports, and application information accumulate over time, giving you insight into what attackers and researchers are looking for.
Figure 5-6. T-Pot Kibana output
In our opinion, honeypots are a great way to proactively collect data that you would otherwise have a hard time getting. It is a rich dataset that we do not see from normal logs. If you place the honeypot close to your datacenter edge, you can see exactly the potential threats to your digital assets.
DDoS-as-a-Service
When you have built up your DDoS mitigation shield, you need to stress test your own system by using the same tools that a potential attacker would use. Along with tools outlined earlier in the book, DDoS-as-a-Service can be a source to perform such test.
Check Your Local Laws and Regulations
As you can imagine, the DDoS-as-a-Service providers sometimes operate in a gray area. Be sure to check your local laws and regulations before you use their services.
You can spend time to become acquainted with a broad set of Booter systems. These might be the very systems that are being used to attack you from. Most will let you set up an account without giving them any payment information. We would recommend being as safe as possible with the addresses that you use to sign up for such a service. Use common sense in these cases: do not connect from your corporate IP address or personal or corporate email addresses; instead, use a throwaway email address.
Once you are confirmed, login and look at the current running attacks and the time periods they have been running for. Also check out the types of attacks that they offer and the overall attack volume that they claim. As a bonus take note of the source IP addresses that the attack traffic comes from. If you are testing using an attack that is not spoofed then you are seeing the real IP address of an attacker and can add this to round off your threat intelligence system.
Unfortunately, as local laws vary wildly regarding DDoS-as-a-Service systems, it would not be responsible for us to recommend going further than a small-scale stress test.
Summary
In this chapter, you learned a number of ways to leverage community-based systems to construct a DDoS-focused threat intelligence system. This includes various IP lists that you can use for your own IP blacklist to block potential malicious sources. You also saw examples of tools such as Cowrie and T-Pot that can be used as honeypots for information gathering.