- freely available
Computers 2019, 8(4), 81; https://doi.org/10.3390/computers8040081
2. Related Literature and Significance of This Study
3. IP Spoofing IN and OUT of the Cloud: Possible Scenarios
3.1. Adversary Leveraging VPS to Attack 3rd Party
- Step (1)
- Subscribe to a VPS hosting plan with a Cloud service provider with loose Internet traffic regulations towards IP spoofing;
- Step (2)
- Choose to have this VPS specifically hosted by one of the Cloud’s servers located in a geographic area (i.e., attached to an ISP) that also has lenient rules about IP spoofing;
- Step (3)
- Use such VPS to run the attack script that generates the intended spoofed packets/traffic.
- The hacker would deploy ‘randomly’ spoofed source IP addresses (i.e., each generated packet would carry a different randomly generated source IP address) if he is conducting a direct attack on the target machine and is not concerned where the response packets generated by the target machine are going to end up, as shown in Figure 3a. (Here we assume that the spoofed IP packets are actually the ‘carriers’ of other higher-layer packets, such as ICMP or TCP, which in the majority of cases prompt the receiving machine to generate a response packet. The packet responses generated by the target machine receiving randomly spoofed IP packets are referred to as backscatter ).
- The hacker would use ‘specifically’ spoofed source IP addresses (i.e., all generated packets would carry the same forged source IP address) if the actual target of his attack is not the machines receiving the spoofed packets. Instead, the hacker is simply exploiting these ‘intermediate’ machines as ‘packet reflectors’, while the true target of his attack is another ‘specific’ machine. Put another way, the actual target of such an attack is the recipient of the backscatter traffic, as shown in Figure 3b. For more on the difference between direct and reflected attacks, see [14,15,21,22].
3.2. Adversary Attacking VPS
3.3. Adversary Using VPS as a Packet Reflector
4. Motivation and Objectives of Our Study
- Question (1)
- How clearly, if at all, the concept and dangers pertaining to IP spoofing are addressed in the acceptable-use (AU) and terms-of-service (ToS) policies of some of the leading real-world Cloud service providers.
- Question (2)
- How successful an attacker owning a VPS with a real-world public CSP would be in sending spoofed IP packets out of this provider’s network to conduct the attacks of Figure 3. Or, looking from the opposite perspective—how effective real-world public CSP is in spotting and blocking outgoing spoofed IP packets generated by their malicious customers.
- Question (3)
- How successful would an attacker be in sending spoofed IP packets to a VPS (IP address) of a real-world public CSP when conducting the attacks of Figure 4 and Figure 5. Or, looking from the opposite perspective—how effective real-world public CSP are in spotting and blocking spoofed IP packets from reaching their servers.
5. IP Spoofing in AU and ToS Policies of Real-World CSPs
6. Transmission of Spoofed IP Packets To and From Select Public CSPs
6.1. Experimental Framework
- 184.108.40.206 is unallocated while 172.16.1.100 is a private IP address . Hence, no packet going into or coming out of the Internet should carry either of these as its source IP address.
- 220.127.116.11 is the IP address of a well known public Google DNS server, and DNS servers generally do not engage in the transmission of ICMP Echo Requests.
- A machine or a VPS should not be receiving an ICMP Echo Reply unless this machine/VPS has explicitly sent an initiating ICMP Echo Request.
- The most widely known passive defense technique against IP spoofing is the so-called TTL-validation [27,28]. Namely, TTL is an 8-bit field in a packet’s IP header, and among its other important purposes can be used by the packet’s receiving machine to compute the hop-distance to the packet’s sending machine. By recording the TTL values of distinct source IP addresses over a period of time, the receiving machine can learn which values are expected from which particular host, and using this knowledge can subsequently be able to identify suspicious/spoofed packets. Now, the common initial values of TTL set by different operating systems are 64 and 128, 256. It can be easily confirmed that the initial TTL value specifically set by the machine(s) corresponding to IP 18.104.22.168 is 64. Consequently, a machine, server or a firewall set to perform TTL-validation on packets arriving from the key Internet servers (including DNS server 22.214.171.124) should be easily able to spot and flag a packet that was sent with the initial TTL = 40 as suspicious. According to , the average hop distance in the internet is 15.3 ± 4.2. Thus, when receiving a packet from the DNS server 126.96.36.199, even the most distant destinations/machines would likely see a TTL ≥ 40. However, a spoofed packet with the initial TTL = 40 would arrive at its destination with the value likely well below 40, which (as previously stated) should be sufficient to flag this packet as anomalous, as per our last packet probe in Table 3.
6.2. Experiment 1 Results: Transmission of Spoofed Packets From Select CSPs’ Networks
6.3. Experiment 2 Results: Transmission of Spoofed Packets Into Select CSPs’ Networks
- Transmission of ICMP Echo Requests with Spoofed Source IP = 188.8.131.52. These spoofed IP packets successfully reached our VPSs on 9 of 12 evaluated Cloud providers. However, as previously explained, 184.108.40.206 is an unassigned IP address, and the ingress firewall of any well-configured Cloud provider should be able to screen for and prevent these packets from entering the respective CSP’s network.
- Transmission of ICMP Echo Requests with Spoofed Source IP = 172.16.1.100. These spoofed IP packets successfully reached our VPSs on 2 of 12 evaluated Cloud providers. However, recall that 172.16.1.100 is a private IP address, and again a well-configured ingress firewall should be able to screen for and prevent these packets from entering the respective Cloud provider’s network.
- Transmission of ICMP Echo Requests with Spoofed Source IP = 220.127.116.11. As shown in Table 5, these spoofed IP packets successfully reached our VPSs on 11 of 12 evaluated Cloud providers, and (more importantly) eight of these VPSs automatically generated an ICMP Echo Response (back) to IP = 18.104.22.168—including the VPSs hosted by AWS. We believe this observation is particularly worrisome, for two reasons:
- First, as previously explained, DNS servers are generally very unlikely to send/initiate ICMP requests—something a well-configured ingress firewall should be cognizant of. (ICMP requests are typically generated by client machines to probe a server or another client machine).
- Moreover, by receiving these requests and responding to them, the servers of the examined Cloud providers could be potentially exploited as reflector points in an attack on the actual DNS server 22.214.171.124, as illustrated in Figure 5. (Given the critical importance of the DNS server 126.96.36.199, any attack on this server can have far-reaching consequences for the entire Internet, and should be prevented by all possible means and by all potentially involved parties).
- Transmission of ICMP Echo Requests with Spoofed Source IP = Receiver’s Own (Destination) IP. Spoofed IP packets in this category successfully reached our VPSs on 9 of 12 evaluated Cloud providers; moreover, four of them also responded to the given request. This result is also very concerning, for two reasons:
- A well-configured ingress firewall should not only be able to screen for and drop any incoming packet that carries the same source and destination IP address but should also be able to flag and drop any packet arriving from the wide-area Internet with an internal IP as its source address. Yet, the firewalls of nine tested Cloud providers failed to do so, including the ones of AWS and Google Cloud.
- Machines or servers/VPSs that respond to ICMP requests with their own IP as both the source and destination address are particularly vulnerable to the so-called ICMP Land attack . Our experimentation identified four such VPSs, again including those hosted by Google Cloud and AWS.
- Transmission of ICMP Echo Replies with Spoofed Source IP = 172.16.1.100. Spoofed IP packets in this category successfully reached our VPSs on two of the tested Cloud providers. A reason why these probes should have ideally been dropped by all Cloud providers, besides the fact that they carried a private IP address as their source, is the fact that these were entirely unsolicited Echo Replies—something any well-configured stateful firewall should ideally be able to pick on.
- Transmission of ICMP Echo Replies with Spoofed Source IP = 188.8.131.52. Spoofed IP packets in this category successfully reached our VPSs on nine of the tested Cloud providers. As in the case of (e), a well-configured stateful firewall should ideally be able to flag these probes as unsolicited/anomalous, and ideally drop them.
- Transmission of ICMP Echo Rsequests with Spoofed Source IPs of 172.16.1.100 and 184.108.40.206, and TTL = 40. Spoofed IP packets in these two categories successfully reached our VPSs on 2 and 11 of the tested Cloud providers, respectively. Here, it is particularly striking that all but one tested Cloud provider allowed the (spoofed) IP = 220.127.116.11 requests with clearly invalid TTL values into their network, this even though the TTL-validation technique is widely known and relatively simple to implement (as discussed in Section 6.1).
7. Conclusions and Future Work
Conflicts of Interest
- Breeden, B.; Lclaughlin, M.; Sindicich, N.; Valentine, A. The C-SAFE Program and the Florida Cyber-Security Manual. Florida Department of Law Enforcement. November 2004. Available online: http://www.secureflorida.org/vendorimages/secureflorida2007/web/C-SAFE/CSAFEcybersecuritymanual.pdf (accessed on 1 November 2019).
- MANRS–Mutually Agreed Norms for Routing Security. Available online: https://www.manrs.org/ (accessed on 28 October 2019).
- CAIDA: Center for Applied Internet Data Analysis. Available online: https://www.caida.org/ (accessed on 28 October 2019).
- ITPRO. Public Cloud Used to Power Supercharged DDoS Attacks. September 2018. Available online: https://www.itpro.co.uk/public-cloud/31884/public-cloud-used-to-power-supercharged-ddos-attacks#gref (accessed on 28 October 2019).
- Pohle, T. Public Cloud Services Increasingly Exploited to Supercharge DDoS Attacks: New Link11 Research. September 2018. Available online: https://www.link11.com/en/blog/public-cloud-services-increasingly-exploited-to-supercharge-ddos-attacks-new-link11-research/ (accessed on 28 October 2019).
- Cimpany, C. Operator of Eight DDoS-for-Hire Services Pleads Guilty. February 2018. Available online: https://www.zdnet.com/article/operator-of-eight-ddos-for-hire-services-pleads-guilty/ (accessed on 28 October 2019).
- Cloud Security Alliance (CSA). The Treacherous 12: Cloud Computing Top Threats in 2016. February 2016. Available online: https://downloads.cloudsecurityalliance.org/assets/research/top-threats/Treacherous-12_Cloud-Computing_Top-Threats.pdf (accessed on 28 October 2019).
- Singh, S.; Jeong, Y.-S.; Park, J.H. A survey on cloud computing security: Issues, threats, and solutions. J. Netw. Comput. Appl. 2016, 75, 200–222. [Google Scholar] [CrossRef]
- Ali, M.; Khan, S.U.; Vasilakos, A.V. Security in cloud computing: Opportunities and challenges. J. Inf. Sci. 2015, 305, 357–383. [Google Scholar] [CrossRef]
- Subramanian, N.; Jeyaraj, A. Recent security challenges in cloud computing. J. Comput. Electr. Eng. 2018, 71, 28–42. [Google Scholar] [CrossRef]
- Kumar, R.; Goyal, R. On cloud security requirements, threats, vulnerabilities and countermeasures: A survey. J. Comput. Sci. Rev. 2019, 33, 1–48. [Google Scholar] [CrossRef]
- De Donno, M.; Giaretta, A.; Dragoni, N.; Bucchiarone, A.; Mazzara, M. Cyber-Storms Come from Clouds: Security of Cloud Computing in the IoT Era. MDPI J. Future Internet 2019, 11, 127. [Google Scholar] [CrossRef]
- Rathore, S.; Park, J.H. Semi-supervised learning based distributed attack detection framework for IoT. J. Appl. Soft Comput. 2018, 72, 79–80. [Google Scholar] [CrossRef]
- Somani, G.; Gaur, M.S.; Sanghi, D.; Conti, M.; Buyya, R. DDoS attacks in cloud computing: Issues taxonomy, and fugure directions. Elseiver Comput. Commun. J. 2017, 107, 30–48. [Google Scholar] [CrossRef]
- Osanaiye, Q.; Choo, K.-K.R.; Dlodlo, M. Distributed denial of service (DoS) resilience in cloud: Review and conceptual cloud DDoS mitigation framework. J. Netw. Comput. Appl. 2016, 67, 147–165. [Google Scholar] [CrossRef]
- Osanaiye, O.A.; Dlodlo, M. TCP/IP header classification for detecting spoofed DDoS attack in Cloud environment. In Proceedings of the EUROCON, Salamanca, Spain, 8–11 September 2015. [Google Scholar]
- Hong, J.B.; Nhlabatsi, A.; Kim, D.S.; Hussein, A.; Fetais, N.; Khan, K.M. Systematic identification of threats in the cloud: A survey. J. Comput. Netw. 2018, 150, 46–69. [Google Scholar] [CrossRef]
- Singh, G.K.; Somani, G. Cross-VM Attacks: Attack Taxonomy, Defence Mechanisms, and New Directions, Part of Versatile Cybersecurity-Advances in Information Security book series (ADIS). Springer 2018, 72, 257–286. [Google Scholar]
- Agrawal, N.; Tapaswi, S. A Lightweight Approach to Detect the Low/High Rate IP Spoofed Cloud DDoS Attacks. In Proceedings of the IEEE International Symposium on Cloud and Service Computing (IEEE SC2), Kanazawa, Japan, 22–25 November 2017. [Google Scholar]
- Osanaiye, O.A. Short Paper: IP spoofing detection for preventing DDoS attack in Cloud Computing. In Proceedings of the IEEE International Conference on Intelligence in Next Generation Networks (IEEE ICIN), Paris, France, 17–19 February 2015. [Google Scholar]
- Yao, G.; Bi, J.; Vasilakos, A.V. Passive IP Traceback: Disclosing the Locations of IP Spoofers from Path Backscatter. IEEE Trans. Inf. Forensics Secur. 2015, 10, 471–484. [Google Scholar] [CrossRef]
- Chang, R.K.C. Defending against Flooding-Based Distributed Denial-of-Service Attacks: A Tutorial. IEEE Commun. Mag. 2002, 40, 42–51. [Google Scholar] [CrossRef]
- Netscout. 14th Annual Worldwide Infrastructure Security Report. March 2019. Available online: https://www.netscout.com/press-releases/netscout-releases-14th-annual-worldwide-infrastructure (accessed on 28 October 2019).
- Cimpanu, C. Russia Bans 1.8 Million Amazon and Google IPs in Attempt to Block Telegram April 2018. Available online: https://www.bleepingcomputer.com/news/government/russia-bans-18-million-amazon-and-google-ips-in-attempt-to-block-telegram/ (accessed on 28 October 2019).
- Valls-Prieto, J. Handbook of Research on Digital Crime, Cyberspace Security, and Information Assurance; IGI Global: Hershey, PA, USA, 2014. [Google Scholar]
- Herath, T.; Rao, H.R. Protection motivation and deterrence: A framework for security policy. Eur. J. Inf. Syst. 2009, 18, 106–125. [Google Scholar] [CrossRef]
- Beverly, R.; Berger, A.; Hyun, Y. Understanding the Efficacy of Deployed Internet Source Validation Filtering. In Proceedings of the 9th ACM SIGCOMM Conference, Chicago, IL, USA, 4–6 November 2009; pp. 356–369. [Google Scholar]
- Wang, H.; Jin, C.; Shin, K.G. Defense against Spoofed IP Traffic Using Hop-Count Filtering. IEEE/ACM Trans. Netw. 2007, 15, 40–53. [Google Scholar] [CrossRef]
|Attack Scenario||adversary leveraging VPS to attack 3rd party (described in Section II.A)||adversary attacking hosted VPS (described in Section II.B)||adversary using VPS as a packet reflector (described in Section II.C)|
|Variants of the attack||randomly spoofed IP packets||specifically spoofed IP packets||spoofed packet sent from a single machine||spoofed packet sent from multiple machine||spoofed packet sent from a single machine||spoofed packet sent from multiple machine|
|Flow of Spoofed IP Packets||out of the public Cloud provider’s network||into the public Cloud provider’s network||into the public Cloud provider’s network|
|Cloud Service Provider (CSP)||IP Spoofing in CSP’s AU and ToS Policy|
|alibabacloud.com||forging TCP/IP header prohibited|
|arubacloud.com||no explicit mention|
|aws.amazon.com||forging TCP/IP header prohibited|
|azure.microsoft.com||no explicit mention|
|bigrock.dom||no explicit mention|
|bluehost.com||forging message headers prohibited|
|buyvm.net||no explicit mention|
|cloud.google.com||no explicit mention|
|cloudvps.com||no explicit mention|
|deltahost.ca||forging TCP/IP header prohibited|
|digitalocean.com||misleading TCP-IP header prohibited|
|dostinger.com||packet corruption prohibited|
|go4hosting.in||no explicit mention|
|godaddy.com||no explicit mention|
|hetzner.com||fake source IPs prohibited|
|hostinginchina.com||IP spoofing prohibited|
|hostsailor.com||forging TCP/IP header prohibited|
|hostslayer.com||forging TCP/IP header prohibited|
|ideastack.com||no explicit mention|
|justhosting.ru||no explicit mention|
|king-servers.com||false message headers prohibited|
|liquidweb.com||no explicit mention|
|miran.ru||falsified IP addresses prohibited|
|parkinhost.com||no explicit mention|
|ramnode.com||IP spoofing strictly prohibited|
|sakuraserver.com||no explicit mention|
|scaleway.com||no explicit mention|
|seedvps.com||falsifying of packet header prohibited|
|swiss-vps.com||no explicit mention|
|unixhost.com||no explicit mention|
|veesp.com||no explicit mention|
|vps.net||no explicit mention|
|vultr.com||no explicit mention|
|znetliev.com||forging TCP/IP header prohibited|
|Type of Packet||Different Spoofed Source IP Addresses Tested|
|IP packet carrying an ICMP Echo Request||18.104.22.168|
Receiver’s own IP (IP of the VPS running the listening script)
|IP packets carrying an ICMP Echo Reply||172.16.1.100|
|IP packet with TTL=40 carrying an |
ICMP Echo Request
© 2019 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).