今天我们来学习关于“云服务器如何防止黑客入侵?”的内容,下文有详解方法和实例,内容详细,逻辑清晰,有需要的朋友可以参考,希望大家阅读完这篇文章后能有所收获,那么下面就一起来了解一下吧。
网络安全是互联网永不过时的主题,尤其是在云计算时代,大量的计算机应用迁移到云端,庞大的IT资产集结在云数据中心,一旦云数据中心爆发安全险情,轻则大量服务停摆,重则敏感数据丢失、系统遭到破坏,损失不可估量。国内几大头部云服务提供商,近一年都发生过网络运行或安全事故,抛开经济损失不提,作为顶级IT巨头出现安全问题难免尴尬,授人以柄、影响声誉。
本文讲述今天发生的一起黑客入侵事件,网络红客与黑客攻防对战。作者带您一步步揭开黑客攻击计算系统的内幕,也讲述网络红客如何绝地反击。
黑客身手不俗,深夜凌晨悄然侵入云服务器,步步为营,沿路设置重重障碍,就像冷兵器时代的铁蒺藜、铁拒马洒满一路,设下重重机关,牵一发而动全身,维系木马程序存在。
然并卵非也,魔高一尺,道高一丈。我们想象中,网络红客高举网安利剑,直入特洛伊城,层层深入,抽丝剥茧,把黑客设下铁蒺藜一根根拔出,轻松拆解隐秘机关,最后堵上城防漏洞,恢复城市的健康和生机。这里的特洛伊城就是中招的云服务器。还可能留下一具木马僵尸标本,以供将来拆解、把玩。哈哈!
事实果真如此吗?
闲话少叙,我们直奔主题,欣赏一场红客、黑客攻防战的来龙去脉和惊险场景。
从这个例子也感悟到,我们以为的真相其实只是表象,看到的表象是更浅显的表象。就像俄罗斯套娃,一层套一层,不到最后一刻永远不知道是否抵达真相。
最近一个月,同事们抱怨公司JIRA服务器变慢了,而且越来越慢,点击页面几秒才有响应,几个人同时点页面,圆圈能不能转出来看运气。最近我忙着做K3s系统迁移,对JIRA没有太在意,也没有关注PR和缺陷报告。
直到昨天,发现软件产品的有个页面不符合我带有洁癖的审美,小伙伴们怂恿我提交一条PR,我才去打开久违了的JIRA首页。没想到JIRA不给力,点登录后圆圈转啊转啊,就是不出来工作台。还不给面子,报告账号密码错。换Chrome浏 览器登录,还是账号、密码错。我的账号、密码是记在电子本本上的,排除人为因素,仅仅拷贝是不可能出错的。
那个无限旋转的圆圈,一点点消磨我的耐心。圆圈能不能求得圆满,以至于怀疑人生。哈哈。
此路不通,能否择歧路而行?用安全邮箱修改JIRA密码后,再登录圆圈消失了,正常登录进去。然后,一波未平一波又起,新建PR页面,出现白屏几分钟无响应。
此间不明一定有暗鬼。
小伙伴们的无助和我的切肤之痛,激发了我的好奇心和正义感。
明知山有虎,偏向虎山行。我不入地狱谁入地狱。
人不可雀语,语雀愿助人。语雀耳语于我,告知JIRA的账号密码和访问路径。JIRA服务器架设在阿里云数据中心,云端SSH直连通道关闭,只能用堡垒主机作跳板二次登录才能访问JIRA服务器。架设JIRA的人士用心于安全可谓良苦。
前奏有点慢节奏,不过某国大片不经常是这样的开头的吗,平静的生活危机四伏。
系统响应慢,习惯性地先看系统资源利用情况。输入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%,不要重复计算。
sd-pam进程像疯狂的野兽吞噬着CPU。去研发大群里询问,没有人能说清楚sd-pam进程是什么来头。疑云骤起,关注点向sd-pam进程聚焦。
提交PR还得仰仗JIRA服务,JIRA服务是运行在Docker容器内的。登录到JIRA容器,查看Java虚拟机参数,堆空间最大可用缺省值是768MB,对于JIRA服务来说显然偏低。而云服务器16GB内存还有10GB以上的空闲,闲着也是闲着,堆空间最大可用值拟修改为2GB。因为运行环境和文件权限问题,在容器内不好修改文件,所以用docker cp命令把环境设置文件setenv.sh拷贝到宿主机,修改后拷贝回JIRA容器。
在大群里喊一嗓子,要重启JIRA服务了,没人理,过几分钟就reboot云服务器了。
重启后,JIRA服务的配置会生效,JVM堆空间会扩大,对改善JIRA服务会有帮助。我也想看看云服务器重启后,sd-pam进程会不会还在。
修改JIRA配置与黑客对战没啥关系,不过是举手解JIRA之困境。
重启云服务器后,sd-pam进程依然顽固地存在,撒着欢一样把CPU利用率拱到满格400%。
“你来或不来我都在这里,不多不少,4个CPU全是我的菜。” 清哥哥感觉被挑衅了,看来得好好伺候这位爷了。
思绪开始往木马、蠕虫方向去想了。但凡木马都不是孤立的,要与外界联系,云服务器联系外界唯一的通道是网络通信。我想看看sd-pam都联系了哪些网络地址。实用工具lsof能查看进程打开的所有文件描述符。文件描述符有点抽象,但是说建立的TCP连接、打开的文件/目录、建立的管道都是文件描述符,就不难理解了。而进程打开的文件和建立的TCP连接正是我想知道的,以后有妙用。
在CentOS上,缺省地没有安装实用命令lsof,通过yum自动下载安装。
1 yum install -y lsof
安装好以后迫不及待想看看sd-pam都干了啥。输入lsof命令,带参数-p PID,PID是进程ID。
1 # lsof -p 11320
图 sd-pam进程打开的文件描述符
分析命令输出,发现两个疑点:
第一个疑点是被删除的文件:/var/tmp/dbus/.sd-pam/sd-pam(deleted)。
第二个疑点是从本机连接到未知远端IP的TCP连接: jira-wiki-nexus:55916->128.199.136.211:http。
连接外网的TCP连接很常见,先从第二个未知TCP连接下手。这个TCP连接指向HTTP端口,用浏览器打开网址,页面显示Mining Proxy Online。Mining,不是Mine,不就是挖矿吗?它自我暴露了。
换一个Google Chrome访问网址看看,输出还是Mining Proxy Online。
再试一试curl命令,都说在挖矿,很诚实的样子。
上午怼黑客时,并没有注意到Mining这个词,只是猜测可能是挖矿,要不然找个“肉鸡”干嘛呢?
百度一下,看看IP来自何方。百度虽然有很多槽点,但是引入的IP查询工具还是实用的。查询结果显示远端IP来自新加坡,是部署在海外的主机。而重启主机前的一次lsof显示,远端IP来自美国。之后,杀死过sd-pam不下十次,它又顽固地出现,稳定地连接这个新加坡IP地址。
接着,我想知道进程sd-pam的可执行程序藏身在什么地方。用了find命令去找它,执行时间太长,一时没耐住性子,ctrl+c掐断了。
好吧,先放过它。
进程sd-pam是可执行的,那么就可以用gdb来跟踪调试,深入内部是不是可以窥探内幕。
CentOS缺省也没有安装程开源调试工具gdb,运行yum命令自动下载、安装gdb。
1 # yum install -y gdb
安装好以后,启动gdb,然后输入attach PID(PID需要替换为实际进程号),触碰sd-pam进程并挂载到gdb调试环境。输出显示/var/tmp/dbus/.sd-pam/sd-pam(deleted),该进程的可执行文件不存在。
消失的可执行程序,难道是挥刀删掉自己了吗?很诡异的现象。正常情况下,从可执行文件启动进程后,可执行文件依然存在原处。因为操作系统创建进程时,未必完全加载可执行文件,可能分步加载,运行时仍可能从可执行文件读数据段。进程能否删除启动的可执行文件?此处存疑。
后续分析会揭露可执行文件消失的真相。
因为想要尽快定位故障、解决问题,gdb调试暂告一段落。
消失的可执行文件意味着sd-pam进程的主人不希望可执行文件被发现,那么可执行文件可能隐藏着不为人知的秘密。sd-pam是黑客进程的疑虑进一步加重。
通过百度或谷歌搜索关键字sd-pam,所得搜索结果很少,看起来有关联的搜索结果不过区区两三条,点进去看详情也毫不相干。如果黑客攻击一说成立的话,那么程序文件名是个性化量身定制的,同样的攻击程序在别的受攻击服务器,可 能会使用别的程序文件名。或者,也许这个攻击程序刚出现,没有形成规模和气候,所以网上报告的信息较少。
可执行程序位于目录/var/tmp/dbus/.sd-pam/,这个目录有两个疑点:可执行目录包含tmp,在Windows安装程序时很常见,Linux 系统很少见;子目录.sd-pam是隐藏目录,命令ls -a才能显示出来,ls是看不出来的。目录的两个疑点都指向,sd-pam程序的主人试图掩盖什么,不想让所寄居的云服务器的管理人员发现。
尝试进入目录/var/tmp/dbus,有了新的发现:
1 # cd /var/tmp/dbus 2 3 # ls -ltra 4 5 # more sd-pam
居然看到了sd-pam,不过sd-pam是一小段Shell脚本,用more命令查看文件内容:
这个脚本做了4件事:
S1、创建隐藏子目录.sd-pam。子目录与前面发现的可疑路径吻合。
S2、复制文件x86_64到隐藏子目录.sd-pam,并改名为sd-pam。与前面发现消失的可执行文件完全一致。
S3、启动新复制的sd-pam程序,带有参数-h sd-pam -c。怀疑是以父子进程监控的方式启动:万一子进程死亡,父进程依然能fork出新的子进程。这样大大增加sd-pam程序存活的几率。
S4、删除S1创建的子目录.sd-pam,连同子目录下可执行文件sd-pam也一并删除。这就解释了前面的谜团:sd-pam进程存在,而进程的可执行程序文件却神秘地消失了。因为脚本sd-pam是以root用户身份运行的,删除jira用户运行进程的可执行文件毫无压力,无需提权。虽无根,仍运行。
注意:这里的sd-pam有两个同名版本:一个是Shell脚本sd-pam;另一个是可执行文件sd-pam,由可执行文件x86_64复制、改名而来,不能混淆。
x86_64适用于64位的X86架构芯片,可以想象该程序可能还有x86(32位X86架构芯片)、ARM32、ARM64和SPARC64等多种版本。
前面提到,JIRA云服务器重新启动后,sd-pam进程像幽灵一样存在,挥之不去,牢牢占据CPU排行榜的首位。应该是有某一种机制能够自动启动sd-pam。
已知的第一种机制是Linux后台服务管理,在系统重新引导后会自动运行,这是Linux内部机制,潜伏的进程只要不被发现,完全可以长期潜伏、定期送出有价值的信息。
第二种机制就要复杂得多,来自互联网的漏洞扫描程序,定时扫描云服务器的漏洞,发现漏洞后重新植入木马。第二种机制容易受到网络安全屏障的阻隔,频繁的扫描也容易被网络安全嗅探器发现,主要的云计算中心都提供免费或收费的服务,嗅探、发现漏洞和外部攻击。所以第二种机制/方法,不适合监控已植入木马云服务器,更适合于初次寻找漏洞,或者地毯式搜索云服务器漏洞。
在不重启云服务器时,直接杀死sd-pam进程能快速的停止木马进程。Linux命令kill传递信号参数SIGKILL或者9能立即杀死进程。
1 # kill -9 11320
杀死进程后,CPU利用率立即下降到个位数。遗憾的是一两分钟后,sd-pam幽灵又出现在top命令输出榜首。
一两分钟内重启进程,Linux Service服务监控管理能做到,但又不符合其行为方式。因为杀死sd-pam进程后,服务监控进程立即能感知到,不会等待,而会立即重启新的sd-pam进程。
有另一种Linux定时任务机制,能做到精准到时分,重启后台任务。Linux后台服务crond,定时被唤醒,按照crontab表定义的时间表启动后台任务。
先看看crontab的时间表:
1 # crontab -l 2 3 … 4 5 * * * * * /var/tmp/dbus/./x86_64
图 Crontab定时启动、检查进程sd-pam
又发现了x86_64的踪迹。前面说到,x86_64就是sd-pam的化身和前身,sd-pam是x86_64的拷贝。自动忽略crontab表的第一条时间任务。
定时任务crontab的任务项由五个时间列和一个命令列组成。五个时间列分别是分钟、小时、星期、日、月,如果是数字表示具体时点,如果是*表示所有的时间点。
五个时间列都是*,表示每月每日每星期每时每分,都会运行命令列的程序。翻译过来就是:7*24小时的每一分每一秒都在运行,榨干云服务器的每一分计算力。够狠的吧,比996厉害吧,669也不过如此。
x86_64能干什么,我有点好奇,忍不住手欠,运行了一把。反正CPU已经4个100了,也不会更坏了。
1 # x86_64
提示程序已经在运行。x86_64有自我监控的功能,只运行一份sd-pam进程副本。Crontab里的x86_64应该就是监控sd-pam存活状态的幕后推手。
先在最前面添加#号,注释掉crontab定时任务。斩断一双幕后黑手,那么木马程序sd-pam就会像孤儿一样。再杀了孤儿sd-pam,预期木马就会清除了。
1 # crontab -e
编辑并保存crontab,立即生效。
然后,执行kill -9 PID,果然sd-pam幽灵消失了好一会儿。好一会儿是多久,没读秒,没数数,我也不知道是多久。哈哈。
在彻底击败敌人之前,欢乐的日子总是短暂的。过了好一会儿,sd-pam幽灵又出现了。有些气馁了,怎么办?不过,还没有动绝杀之前,怎么能轻言失败呢?!
回顾一下,不管是Linux服务管理还是Linux Crontab,都要调用/var/tmp/dbus/目录下的程序,那么让它们找不到这个目录,是不是它们就抓瞎了呢?说干就干,斩草要除根,dbus就是sd-pam的根。
1 # cd /var/tmp 2 3 # mv dbus dbus_bak 4 5 # kill -9 PID ## PID替换为sd-pam进程的进程号
这里没有直接删除dbus目录,而是给目录改名,使之找不到dbus目录,与删除目录效果是一样的。黑客攻击现场留下活证据,可作为呈堂证供。哈哈。
如此操作之后,幽灵进程再也没有出现过。又重启了云服务器,幽灵进程也没有出现了,空闲时CPU利用率稳定在个位数。
图 清除木马后云服务器进程列表
从浏览器点击JIRA控制台,在后台监控云服务器,看着JIRA(Java)进程欢快地吞噬CPU,我也长舒了一口,心里的石头落地了。
木马程序是被根除了,但是黑客是怎么攻进来的,云服务器漏洞在哪里,黑客会不会轻车熟路开始下一波攻击,我们一无所知。如果您对此感兴趣,请看下一节。
下文预告:
4、探秘黑客踪
4.1 寓言公寓楼
4.2 查询访客志
4.3 孜孜找不同
4.4 惊现无秘码
4.5 紧锁失密门
4.6 探寻黑客踪
4.7 解读黑客术
4.8 还原入侵图
5、修复云主机
6、安全警示钟
7、详解木马源
8、小结
感谢各位的阅读,以上就是“云服务器如何防止黑客入侵?”的内容了,经过本文的学习后,相信大家对云服务器如何防止黑客入侵?都有更深刻的体会了吧。这里是群英网络,小编将为大家推送更多相关知识点的文章,欢迎关注!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:mmqy2019@163.com进行举报,并提供相关证据,查实之后,将立刻删除涉嫌侵权内容。
长按识别二维码并关注微信
更方便到期提醒、手机管理