The Great ‘Cloud Repatriation’

Cloud Repatriation KB ID 0001859

Cloud Repatriation The Great Cloud Migration Reversal

In the fast-paced world of technology, trends often come and go with dizzying speed. One such trend that took the business world by storm was the mass migration to public cloud environments. For years, companies embraced the promise of agility, scalability, and cost-effectiveness offered by the public cloud. However, recent surveys and industry reports indicate a significant shift in this narrative—a growing number of organizations are repatriating their workloads from the public cloud back to on-premises infrastructures. What’s driving this reversal, and what does it mean for the future of cloud computing?

According to the DC Cloud and AI Adoption Survey dating as far back as 2018, a staggering 80% of customers expressed their intentions to repatriate workloads from public cloud environments. This sentiment has only strengthened over time. Citrix’s recent findings further illuminate this trend, reporting that 25% of organizations surveyed in the United Kingdom have already moved half or more of their cloud-based workloads back to on-premises infrastructures. These statistics paint a clear picture of a paradigm shift in cloud adoption strategies.

One of the primary catalysts for this repatriation movement is cost. While the public cloud initially lured businesses with promises of lower operational expenses, many have found themselves grappling with unexpected costs and complex pricing structures. As organisations delve deeper into their cloud usage, they often discover that the anticipated savings are elusive, overshadowed by hidden fees and overprovisioning. The allure of agility, while undeniable, is no longer enough to offset the financial concerns associated with public cloud services.

Moreover, the recent acquisition of VMware by Broadcom has raised concerns, particularly among small businesses, about the future of their cloud infrastructure. With consolidation in the industry, smaller players may find themselves at the mercy of larger corporations, prompting them to explore alternative solutions such as edge computing or investing in their own on-premises infrastructure.

Another significant factor contributing to the repatriation trend is service reliability. While public cloud providers tout impressive uptime guarantees, the reality is that even the largest hyperscalers are not immune to outages. When a major cloud service goes down, the impact can be catastrophic for businesses reliant on that infrastructure. Clients often feel powerless and insignificant during these outages, underscoring the importance of reliability and customer-centric service.

Storage costs also play a pivotal role in the decision to repatriate workloads. While public cloud providers offer convenient storage solutions, the costs can quickly escalate, especially for organizations with large volumes of data. Hybrid cloud, private cloud, or outsourcing to local providers offer more cost-effective alternatives, with the added benefit of greater control over data management and security.

In conclusion, the pendulum of cloud adoption is swinging back towards on-premises infrastructures as organizations reevaluate their priorities and weigh the trade-offs of public cloud services. While the public cloud undoubtedly revolutionized the way we approach IT infrastructure, its limitations and shortcomings have prompted a reexamination of cloud strategies. As businesses seek to optimize costs, enhance reliability, and regain control over their data, the trend of cloud repatriation is likely to continue gaining momentum in the years to come.

Cloud Repatriation: Client Challenges

Undertaking cloud repatriation poses several challenges for clients. These challenges can vary depending on factors such as the size of the organization, the complexity of their IT landscape, and their specific requirements.  Common challenges facing clients undertaking cloud repatriation:

  • Data Transfer and Migration: Moving data and applications from the public cloud to on-premises infrastructure or alternative cloud environments can be a complex and time-consuming process. Clients must carefully plan and execute data transfer and migration strategies to ensure minimal disruption to their operations and data integrity.
  • Integration and Compatibility: Workloads that were designed to run in a public cloud environment may have dependencies on cloud-specific services or technologies. Clients may encounter challenges when integrating these workloads with their on-premises infrastructure or alternative cloud solutions, particularly if there are compatibility issues or differences in architecture.
  • Resource Allocation and Capacity Planning: Repatriating workloads requires clients to allocate sufficient resources and capacity within their on-premises infrastructure to accommodate the migrated applications and data. Proper capacity planning is essential to ensure optimal performance and scalability without over-provisioning or underutilizing resources.
  • Skill Gaps and Training: Managing on-premises infrastructure or alternative cloud environments often requires different skill sets compared to managing public cloud services. Clients may face challenges related to skill gaps among their IT staff and the need for training or hiring resources with expertise in areas such as infrastructure management, networking, and security.
  • Security and Compliance: Security and compliance considerations are paramount when repatriating sensitive data and applications from the public cloud. Clients must ensure that their on-premises infrastructure or alternative cloud solutions meet the necessary security standards and compliance requirements, including data protection, access controls, and regulatory mandates.
  • Cost Management: While cost savings may be a driving factor behind cloud repatriation, clients must carefully evaluate the total cost of ownership (TCO) associated with migrating workloads back on-premises or to alternative cloud solutions. This includes not only the direct costs of infrastructure, but also factors such as licensing, maintenance, and operational expenses.
  • Service Levels and Performance: Clients may have become accustomed to the scalability and performance benefits of public cloud services and expect similar levels of service from their on-premises infrastructure or alternative cloud solutions. Ensuring that the repatriated workloads meet performance requirements and service level agreements (SLAs) can be a challenge, particularly in highly dynamic or resource-intensive environments.
  • Vendor Lock-In and Flexibility: Repatriating workloads from a specific public cloud provider may involve mitigating vendor lock-in and ensuring flexibility to migrate between different environments in the future. Clients should carefully evaluate vendor dependencies and consider strategies for maintaining portability and avoiding vendor lock-in when repatriating their workloads.

To summarise clients undertaking cloud repatriation face a range of challenges related to data migration, integration, resource allocation, skill gaps, security, cost management, service levels, and vendor lock-in. Addressing these challenges requires careful planning, collaboration between IT teams and stakeholders, and a strategic approach to migrating and managing workloads across different environment.

Related Articles, References, Credits, or External Links

NA

Cisco – Cracking and Decrypting Passwords (Type 7 and Type 5)

KB ID 0000940 

Problem

Decrypt Type 7 Cisco Passwords

The Internet is full of sites that have something like the tool below, tap your ‘encrypted’ password in and it will reveal the Cisco password.

 

Input Type 7 Obfuscated Password: Output Plain Text Password:

As you can see I’ve specifically written ‘obfuscated’ above, because the password isn’t actually encrypted at all. All that happens is the Vigenere algorithm is used to obfuscate the password. While tools like the one above are all well and good, your Cisco router will do exactly the same for you, to demonstrate, paste the following into the tool above.

107D1C09560521580F16693F14082026351C1512

Hopefully you will get the password Sup3rS3cr#tP@ssword.

Your router can also convert that to clear text for you;

[box]

Petes-Router#
Petes-Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Petes-Router(config)#key chain decrypt
Petes-Router(config-keychain)#key 0
Petes-Router(config-keychain-key)#key-string 7 107D1C09560521580F16693F14082026351C1512
Petes-Router(config-keychain-key)#exit
Petes-Router(config-keychain)#exit
Petes-Router(config)#exit
Petes-Router#
*Mar 1 00:04:48.691: %SYS-5-CONFIG_I: Configured from console by console
Petes-Router#show key chain decrypt
Key-chain decrypt:
key 0 -- text "Sup3rS3cr#tP@ssword"
accept lifetime (always valid) - (always valid) [valid now]
send lifetime (always valid) - (always valid) [valid now]
Petes-Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Petes-Router(config)#no key chain decrypt

[/box]

So whats the point of these type 7 passwords? Well the only real benefit of them is if someone is looking over your shoulder while you are looking at the config, they can’t see actual passwords in the config.

The passwords in my config are in clear text? That’s because there are three levels of password storage 0 (not encrypted), 7 (weakly encrypted), and (5 strongly encrypted). If you want to convert your config to display them as 7 you need to enter the service password-encryption command;

[box]

Petes-Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Petes-Router(config)#service password-encryption
Petes-Router(config)#

Before

username pete password 0 Password123

After

username pete password 7 142713181F13253920796166

[/box]

If Type 7 passwords are so weak, how do I use Type 5 passwords? When creating accounts use the secret command like so;

[box]

Petes-Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Petes-Router(config)#username petelong secret Password123
Petes-Router(config)#

Displays in the config as;

username petelong secret 5 $1$VkQd$Vma3sR7B1LL.v5lgy1NYc/

[/box]

Decrypting Type 5 Cisco Passwords

 

Decrypting a Type 5 Cisco password is an entirely different ball game, they are considered ‘secure’ because they are ‘salted’ (have some random text added to the password to create an MD5 hash) however that random salt is shown in the config.

[box]

username attackme secret 5 $1$TMnL$iAFs16ZXx7x18vR1DeIp6/

[/box]

Well armed with the salt and the hash, we can use exactly the same method that Cisco use to create the encrypted password, by brute force attacking the password, this might sound like a difficult piece of hacking ninja skill, but we simply use openssl on a Linux box (here I’m using CentOS 6.5), all you need is a wordlist.txt file (search the Internet).

Feed openssl the salt, and a piece of the hash (see the example above), and it will run through, (grep) the wordlist until it finds a match, where it spits out the decrypted password an the original hash like so;

[box]

[root@pnl-server1 ~]# openssl passwd -1 -salt TMnL -table -in wordlist.txt | grep 8vR1DeIp6
SECRETPASSWORD $1$TMnL$iAFs16ZXx7x18vR1DeIp6/
[root@pnl-server1 ~]#

[/box]

The decrypted password is SECRETPASSWORD

Note: The limitation here is the password has to be in the wordlist.txt file,but if you are adept at searching the Internet there are some impressive wordlist files out there, just make sure you use one that has full line breaks. Also remember, the longer the wordlist, the longer it takes.

Related Articles, References, Credits, or External Links

NA