分享一次应急响应简述
source link: https://www.tuicool.com/articles/jq6JNjr
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
一、背景
几周前接到某单位管理人员电话，说“您好，我单位某系统受到攻击，现系统已瘫痪（想到系统已瘫痪，心理特别慌张，要写溯源报告了），应用无法使用，需到现场进行排查”，随后简单问了一下网络情况，就匆匆赶往客户现场。
通过电话了解到的大致内容为：该系统已处于瘫痪状态、系统属于内网未对互联网开发端口、操作系统为Windows server 2008、已做断网处理。
二、现场排查
经过2小时后到达客户现场，再次与系统管理人员确认情况，得到的信息与电话沟通的内容差不多。原本想先进入系统看看情况，确认一下问题，可是有其他厂家的人员在看，也不好意思，就等着看他操作，一等就等了1个小时。这期间他主要操作还是在看系统安全日志，日志查看一直追溯到事发前1周时间，在日志的查看中并没有发现问题，如果是我在操作我也会先查看一下日志。
2.1、着手排查
通过之前的等待和其他人员的排查，在系统安全日志上并未发现存异常问题。到这里想到网络瘫痪于是有了以下想法：
想法1：系统遭受到类似于DOS或者DDOS之类的攻击；
想法2：系统存在web应用类漏洞，可能被上传了shell，系统被控制了。
但想到该系统未开发应用到互联网上，以上想法就不能成立，黔驴技穷了，一下子没思路了，不能刚刚接手鼠标和键盘就没有操作呀。顿时冷静了一下，想到既然是应用瘫痪了，那先看看网络活动的 TCP 连接情况。于是我用nestat -ano查看了tcp的连接情况，输入完netstat -ano回车后，我的妈呀！什么情况，为什么会有那么多tcp的连接，我倒是惊讶了，足足登录2分钟信息才刷新完，刷新完成后，发现有太多的TIME_WAIT等待了。
为了看的更清楚，我使用了netstat -ano | more命令，然后一页一页的翻，发现单位内部与该应用系统有通信IP的40000或50000以上的端口均处于TIME_WAIT状态。这让我想到了Windows 2008R2大量回话在TIME_WAIT状态的一个BUG，在系统启动时从 497 天后所有在TIME_WAIT状态的 TCP/IP 端口都不会被关闭。因此， TCP/IP 端口可能会被用光，并且可能不会创建新的 TCP/IP 会话。
到这里我将得到的信息反馈给管理人员，并询问了系统的开机时间，该系统已开启了500多天。管理人员并不是很接受，并说出了新的问题（这是我有开始有点慌了，难道不是这个问题嘛）“后台程序出现接口无法调用的问题”：
看到相关报错后，我更确认了我之前的想法。为了验证我的想法，我将之前看到的博客与微软的通告信息给管理人员看，最终确认问题。
相关连接如下：
windows 2008 R2 大量会话在TIME_WAIT状态
socket-详细分析No buffer space available（转载）
该问题确认后，我又对系统进程和服务进行排查，发现该系存在WannaCry勒索病毒的服务，但未发现相关勒索病毒进程，并在杀毒软件的恢复区发现了WannaCry的文件。
通过询问后，发现该病毒在18年6月份已被删除过，但是由于系统未重启，该服务还存在，最后我清理注册表。
相关操作完成后，联系管理员重启系统，整个过程花费时间不到半个小时，最终解决问题。
三、总结
通过这次应急，我认为管理人员有时提供的信息与应急人员所需求的可能不同，很可能会误导应急人员。作为应急人员，应该有很强的逻辑能力和分析能力，另外还需要拥有自信。
新手上路，大佬勿喷，感谢。
*本文原创作者：bbbbbbig，本文属于FreeBuf原创奖励计划，未经许可禁止转载
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK