云基础架构安全_您的云基础架构暴露程度如何

云基础架构安全

Cloud computing is one of the hottest trends in today’s IT world. Companies are racing to switch from on-premises data centers to using public clouds such as AWS, Azure and Google Cloud. Even the United States DOD has decided to move it’s infrastructure to the cloud. The contract was won by Azure who bested AWS in the last stage of the bid for a 10 billion dollar contract for 10 years. This move highlights the importance of cloud computing in providing a resilient infrastructure that can handle increasing amounts of data while keeping costs at a minimum.

云计算是当今IT世界中最热门的趋势之一。 公司正竞相从本地数据中心转换为使用AWS，Azure和Google Cloud等公共云。 甚至美国国防部也已决定将其基础架构迁移到云中。 该合同由Azure赢得，他在竞标的最后阶段击败AWS，获得了为期10年的100亿美元合同。 此举凸显了云计算在提供可恢复的基础架构中的重要性，该基础架构可处理不断增加的数据量，同时将成本保持在最低水平。

However, with cloud computing comes new challenges. Hosting your enterprises’ entire digital infrastructure on a public cloud will expose you to more cyber-threats than on-premises approaches. The fact that your traffic will pass through the public internet network will mean that you are exposed to traffic analysis and sniffing attacks. Address spoofing and Man in The Middle attacks are also a possible risk. In essence, whenever an IT system is connected to a public network the security risk increases considerably.

但是，云计算带来了新的挑战。 在公共云上托管企业的整个数字基础架构将使您面临比内部部署方法更多的网络威胁。 您的流量将通过公共Internet网络的事实意味着您将遭受流量分析和嗅探攻击。 地址欺骗和中间人攻击也是可能的风险。 本质上，每当IT系统连接到公共网络时，安全风险就会大大增加。

But I am a simple student running some labs and websites to learn and test new concepts and software, what possible risks could I face? after all there is almost nothing to gain by spending resources and time to launch an attack on my “cloud infrastructure”. Or so did I think!

但是我是一个简单的学生，他经营着一些实验室和网站来学习和测试新概念和软件，我可能面临什么风险？ 毕竟，花费资源和时间对我的“云基础架构”发起攻击几乎没有任何收获。 还是我想！

故事 (The story)

I have a friend who is majoring in cybersecurity and he was doing a project that aims to collect logs from an IT system and analyze them to generate IOCs also know as Indicators of compromise. He was working with OpenIOC and other opensource tools. To generate these IOCs, you need to get your hands on the logs of a compromised system or simulate attacks in a controlled environment and collect the generated logs and analyze them. However, has was running low on time and he faced a problem with his current Kali installation so I decided to use Azure and launch a penetration testing machine based on a Kali Linux image. This made sense since the target system was also running on the cloud(obviously all the needed precautions from installing a firewall to configuring strict ACLs to limit access).

我有一个主攻网络安全的朋友，他正在做一个旨在从IT系统收集日志并对其进行分析以生成IOC(也称为危害指标)的项目。 他正在使用OpenIOC和其他开源工具。 要生成这些IOC，您需要掌握受感染系统的日志，或者在受控环境中模拟攻击，并收集生成的日志并进行分析。 但是，由于时间紧迫，他当前的Kali安装遇到了问题，所以我决定使用Azure并启动基于Kali Linux映像的渗透测试机。 这是有道理的，因为目标系统也在云上运行(显然，从安装防火墙到配置严格的ACL来限制访问，所有必要的预防措施)。

All was running well and we simulated the needed attacks and collected the corresponding logs and I shut down the target and firewall VMs. But I left the Kali VM running just in case my friend needed to take some screen captures for his rapport.

一切运行良好，我们模拟了所需的攻击并收集了相应的日志，然后关闭了目标VM和防火墙VM。 但是我让Kali VM保持运行状态，以防万一我的朋友需要为他的关系进行一些截屏。

惊喜 (Suprise)

The next morning, I remembered that I had this Kali machine running and I tried to SSH into it to try and test some things. Surprise! I was unable to connect, my first thought was that Azure shut down the machine or that it might have suffered a system crash. After logging into the Azure console I saw that the current metrics of the instance show that the CPU was running on full load. Network and storage were also running pretty high for a supposedly idle machine.

第二天早上，我想起了我正在运行的这台Kali机器，我尝试通过SSH进入其中，以尝试测试一些东西。 惊喜！ 我无法连接，我首先想到的是Azure关闭了该计算机，或者它可能遭受了系统崩溃。 登录到Azure控制台后，我看到实例的当前指标显示CPU在满负载下运行。 对于所谓的闲置机器，网络和存储的运行也很高。

I decided that it was either a bug that was causing the machine to act weird or a cyber attack that was causing my system to slow down. I first took a look at the network setting and I noticed that the current ACL for TCP port 22 was accepting connections for any IP address! What a mistake! I should have never done this, usually, I would associate the ACL to my IP or the IP range of my university if I am working on campus. However, since I was giving access to someone else I just took the easy way and allowed SSH connections to be accepted from any IP address.

我认为这是导致计算机运行异常的错误，还是导致系统运行缓慢的网络攻击。 首先，我看了看网络设置，发现当前TCP端口22的ACL接受任何IP地址的连接！ 真是个错误！ 我应该从来没有这样做过，通常，如果我在校园里工作，我会将ACL关联到我的IP或大学的IP范围。 但是，由于我可以访问其他人，因此我采取了简单的方法，并允许从任何IP地址接受SSH连接。

I made a snapshot of the current state of the VM and then shut down the instance. I then proceeded to restart the VM but making sure to only allow connections from my static IP address.

我制作了虚拟机当前状态的快照，然后关闭了实例。 然后，我继续重新启动VM，但确保仅允许来自我的静态IP地址的连接。

The CPU utilization dropped to a normal level and so did the networking and disk usage. Since I was only accepting connections of the SSH service I decided to check the authentification logs to see what was going on in the last hours. These logs are located at /var/log/:

CPU使用率下降到正常水平，网络和磁盘使用率也下降。 由于我只接受SSH服务的连接，因此我决定检查身份验证日志以查看最近几个小时的情况。 这些日志位于/ var / log /：

Let’s open it up and take a look inside by typing:

让我们打开它，并键入以下内容以查看内部内容：

sudo cat auth.log

须藤猫认证日志

And an infinite set of strings starts to flow down! This more like the matrix movie and less of a use for me. So let’s narrow down the search a bit by using the powerful grep tool. I would be looking for failed logging attempts using the keyword “failed” this would be a good start:

无限的字符串开始流淌下来！ 这更像是矩阵电影，对我来说却很少。 因此，让我们使用功能强大的grep工具来缩小搜索范围。 我将使用关键字“ failed”来查找失败的日志记录尝试，这将是一个不错的开始：

sudo cat auth.log | grep Failed

sudo cat auth.log | grep失败

Bingo! we have a long list of failed login attempts from a wide range of IP addresses.

答对了！ 我们提供了大量来自各种IP地址的失败登录尝试。

Great! now we can say for sure that we were being attacked by what seems to be a brute force attack on SSH2.

大！ 现在我们可以肯定地说，我们正受到SSH2的暴力攻击。

I noticed someone was using the user name “dovecot” to try and get access so I was curious to see what weird usernames were these people using to try and get in.

我注意到有人使用用户名“ dovecot”来尝试访问，所以我很好奇这些人用来尝试进入的用户名很奇怪。

For that, I used the following command to extract just the usernames and write them to a new file named “usernames.txt”.

为此，我使用以下命令仅提取用户名，并将其写入名为“ usernames.txt”的新文件中。

sudo cat auth.log | grep -oP ‘(?<=invalid user )[^ ]*’ |sort -u > usernames.txt

sudo cat auth.log | grep -oP'(？<=无效用户)[^] *'| sort -u> usernames.txt

The first part will display all of the auth.log entries, the second command “grep -oP ‘(?<=invalid user )[^ ]*’ will only select lines where the “invalid user” pattern is found and will return as output the next following string which will be the username that was used by the attacker to gain access, and the last command will sort these usernames alphabetically and will remove all the repetition as the same username could be used by multiple hackers or by the same hacker multiple times.

第一部分将显示所有auth.log条目，第二个命令“ grep -oP'(？<= invalid user)[^] *”将仅选择找到“ invalid user”模式的行，并以输出接下来的下一个字符串，该字符串将是攻击者用来获取访问权限的用户名，最后一条命令将按字母顺序对这些用户名进行排序，并删除所有重复内容，因为同一用户名可能被多个黑客​​或同一黑客使用多次。

If we examine the output of the operation we get a total of 1037 unique usernames that were used during this attack. These could be used when auditing a system for the existence of an attack attempt by cross-searching the logs of your system.

如果我们检查操作的输出，我们将获得此攻击期间使用的总共1037个唯一用户名。 当通过交叉搜索系统日志来检查系统是否存在攻击尝试时，可以使用这些选项。

It would have been much more interesting if we cloud have collected the passwords that were used during these attempts but unfortunately, the passwords aren’t logged by the system but in the future, such a feature could be added by the administrator.

如果我们云收集了在这些尝试中使用的密码，那将更加有趣，但是不幸的是，密码没有被系统记录下来，但是将来，管理员可以添加此功能。

The next step for me was to extract all of the IP addresses from which these attacks originated. I manually copied a few of them to compare them against known abusers using the AbuseIPDB website:

对我来说，下一步是提取所有发起这些攻击的IP地址。 我使用AbuseIPDB网站手动复制了一些文件，以将它们与已知的滥用者进行比较：

So I extracted all the IP addresses into a single text file as a first step using this command:

因此，我首先使用此命令将所有IP地址提取到一个文本文件中：

sudo cat auth.log | grep -E -o “([0–9]{1,3}[\.]){3}[0–9]{1,3}” | sort > ip_addr.txt

sudo cat auth.log | grep -E -o“([[0–9] {1,3} [\。]){3} [0–9] {1,3}” | | 排序> ip_addr.txt

This will output all the IP addresses that are found in the log file. This is intentional as it allows us to keep track of the frequency of the attacks executed by every single address.

这将输出在日志文件中找到的所有IP地址。 这是有意的，因为它使我们能够跟踪每个地址执行的攻击的频率。

The final list of attackers can be extracted by adding the “-u” parameter to the sort command to get a list of unique addresses.

可以通过在排序命令中添加“ -u”参数来提取最终的攻击者列表，以获得唯一地址列表。

This file was then uploaded to Ipheatmap which is a website that offers a heatmap visualization of the geolocation and frequency of the IP addresses after all an image is worth a thousand words!

然后将该文件上载到Ipheatmap ，这是一个网站，在所有图像都值一千字之后，该文件就可以提供IP地址的地理位置和频率的热图可视化！

You do learn from your mistakes, and this was a great opportunity to learn just how dangerous and how exposed is your infrastructure in the cloud. I did use strong passwords and long RSA keys to secure my machines but it’s always important to configure the network access correctly to protect yourself against these attacks that caused my VM to suffer a high load to the point where I couldn’t connect to it.

您确实可以从错误中学习，这是一个很好的机会，可以了解云中的基础架构有多么危险和暴露程度如何。 我确实使用过强密码和长RSA密钥来保护我的机器，但是正确配置网络访问以保护自己免受这些攻击(使我的VM承受高负载至无法连接的程度)始终很重要。

This entire article aims to show you that even a single machine that is not running any public services can be the target of multiple attacks, so you can imagine the risks that an enterprise can face against more motivated and more resourceful actors. Cloud security shouldn’t be taken for granted and should be a priority to anyone thinking of migrating to the public cloud.

整篇文章旨在向您展示，即使一台未运行任何公共服务的计算机也可能成为多重攻击的目标，因此您可以想象企业可能面临着更有动力，更有智慧的行为者面临的风险。 云安全性不应该被视为理所当然，应该成为任何考虑迁移到公共云的人的优先考虑。

翻译自: https://medium.com/swlh/how-exposed-is-your-cloud-infrastructure-710969b16298

云基础架构安全