网络安全是互联网永不过时的主题，尤其是在云计算时代，大量的计算机应用迁移到云端，庞大的IT资产集结在云数据中心，一旦云数据中心爆发安全险情，轻则大量服务停摆，重则敏感数据丢失、系统遭到破坏，损失不可估量。国内几大头部云服务提供商，近一年都发生过网络运行或安全事故，抛开经济损失不提，作为顶级IT巨头出现安全问题难免尴尬，授人以柄、影响声誉。
本文讲述今天发生的一起黑客入侵事件，网络红客与黑客攻防对战。作者带您一步步揭开黑客攻击计算系统的内幕，也讲述网络红客如何绝地反击。
黑客身手不俗，深夜凌晨悄然侵入云服务器，步步为营，沿路设置重重障碍，就像冷兵器时代的铁蒺藜、铁拒马洒满一路，设下重重机关，牵一发而动全身，维系木马程序存在。
然并卵非也，魔高一尺，道高一丈。我们想象中，网络红客高举网安利剑，直入特洛伊城，层层深入，抽丝剥茧，把黑客设下铁蒺藜一根根拔出，轻松拆解隐秘机关，最后堵上城防漏洞，恢复城市的健康和生机。这里的特洛伊城就是中招的云服务器。还可能留下一具木马僵尸标本，以供将来拆解、把玩。哈哈！
事实果真如此吗？
闲话少叙，我们直奔主题，欣赏一场红客、黑客攻防战的来龙去脉和惊险场景。
从这个例子也感悟到，我们以为的真相其实只是表象，看到的表象是更浅显的表象。就像俄罗斯套娃，一层套一层，不到最后一刻永远不知道是否抵达真相。
2、云机见疑云 2.1 遭遇半瘫机
最近一个月，同事们抱怨公司JIRA服务器变慢了，而且越来越慢，点击页面几秒才有响应，几个人同时点页面，圆圈能不能转出来看运气。最近我忙着做K3s系统迁移，对JIRA没有太在意，也没有关注PR和缺陷报告。
直到昨天，发现软件产品的有个页面不符合我带有洁癖的审美，小伙伴们怂恿我提交一条PR，我才去打开久违了的JIRA首页。没想到JIRA不给力，点登录后圆圈转啊转啊，就是不出来工作台。还不给面子，报告账号密码错。换Chrome浏 览器登录，还是账号、密码错。我的账号、密码是记在电子本本上的，排除人为因素，仅仅拷贝是不可能出错的。
那个无限旋转的圆圈，一点点消磨我的耐心。圆圈能不能求得圆满，以至于怀疑人生。哈哈。
此路不通，能否择歧路而行？用安全邮箱修改JIRA密码后，再登录圆圈消失了，正常登录进去。然后，一波未平一波又起，新建PR页面，出现白屏几分钟无响应。
此间不明一定有暗鬼。
小伙伴们的无助和我的切肤之痛，激发了我的好奇心和正义感。
明知山有虎，偏向虎山行。我不入地狱谁入地狱。
人不可雀语，语雀愿助人。语雀耳语于我，告知JIRA的账号密码和访问路径。JIRA服务器架设在阿里云数据中心，云端SSH直连通道关闭，只能用堡垒主机作跳板二次登录才能访问JIRA服务器。架设JIRA的人士用心于安全可谓良苦。
前奏有点慢节奏，不过某国大片不经常是这样的开头的吗，平静的生活危机四伏。
2.2 初探噬心兽
系统响应慢，习惯性地先看系统资源利用情况。输入top命令，一看吓一跳，有一个sd-pam进程占用CPU接近400%。
图 JIRA服务器系统资源利用情况
输入htop命令进一步查看详情。
图 JIRA服务器系统资源利用详情
从详情页可见，这台云服务器一共有4个CPU核心，4个核心利用率全是100%。可怜的JIRA（Java）进程挤到不知道哪个犄角旮旯里去了，分配的CPU连1%都不到，难怪JIRA会慢得像蜗牛。
CPU利用率排在前5位（1+4）的进程无一例外是sd-pam，第1个进程CPU利用率是396%，紧接着4个进程CPU利用率在99%左右。
大家可能会问，4个核心的主机，5个进程CPU利用率加起来将近800%，怎么像8个核心呢？
Linux是多进程多线程的操作系统，以进程模拟线程，5个进程ID（PID），其实只有一个主进程，其余4个是进程模拟出来的线程，从属于主进程，4个线程的CPU利用率合计等于第1个线程的CPU利用率396%，不要重复计算。