3unshine FreeBuf
本篇主要说明一下遇到拒绝服务***、DNS劫持、IOC告警以及APT事件的常规处理方式。
拒绝服务***拒绝服务***分为两种，DDOS***和DOS***。
DDOS***也称为分布式拒绝服务***，英文全称Distributed denial of service attack，与DOS***存在较大区别。
DOS***可以理解为使用单台主机利用目标系统应用层或系统层的漏洞，使其无法正常提供服务，而DDOS***一般都是通过***控制的大量的肉鸡，结合反射放大等***对目标进行大量流量***，使其无法提供服务。
先讨论DDOS***，这类***通常在防火墙等网络设备能看到目标短时间内遭受了大量的流量***，最明显的表现为网站外网无法正常访问或访问速度非常卡顿，而内网则正常访问没有问题，此时基本可以断定为目标遭受DDOS***。
这类***没有特别好的处理方式，仅给出网上常用的处理建议：
1、特征丢弃，根据数据包的特征或访问行为进行丢弃，如基于Payload特征、发包行为特征等。
2、限速，对流量／访问的速率进行限流。
3、限源，即对源IP或协议进行限制。
还是建议部署安全设备或上云来防止遭受DDOS***。
DOS***一般都是由于系统或应用漏洞导致，最应用层最常见的有apache的slowloris Attack，也是awvs最容易扫出来的问题，msf中自带有相关的扫描脚本。
除此之外，部分DOS***利用系统漏洞使服务器无法正常运行，如经典的MS12020，可以使任意开放了RDP服务并且没有打对应补丁主机蓝屏重启，从而导致无法正常提供服务。
遭遇此类***时，我们应当对系统开放的服务一一进行排查，如果有相关的网络设备可以对受影响主机进行流量监控，确认遭受***的端口与服务，再进行后续分析。
DNS劫持DNS劫持，是指通过***域名解析服务器（DNS）或伪造域名解析服务器（DNS）的方法，把目标网站域名解析到错误的IP地址从而实现用户无法访问目标网站的目的或者蓄意或恶意要求用户访问指定IP地址（网站）的目的。
通常来说存在三种情况：
路由器被***
DNS服务被***
运营商流量劫持
鉴于运营商方面有时沟通无果，本文只讨论前两种情况。
DNS劫持应该优先排查好主机方面的问题，如DNS配置有无问题，本地hosts文件是否被篡改过，浏览器设置是否被改动，前两种情况可以直接查看，浏览器设置问题可以使用360、火绒等杀软直接进行扫描并修复。
路由器被***导致的DNS劫持应该是最常见的场景，由于某些路由器可能映射管理端口到外网，并且有可能存在弱口令和RCE的问题，所以遇到DNS劫持的情况，应当首先更换路由器设备（当前，肯定要换不同的款式），然后查看情况是否解决，如果解决问题，那么针对原路由的口令以及后门RCE漏洞等进行分析，出具相关报告。
如果仍未解决问题，那么考虑DNS服务器是否遭受***。
登录DNS服务器，查看DNS配置是否存在问题，若发现被恶意更改，则确认该事件是由于DNS服务器遭受***导致，需要使用杀软进行病毒查杀扫描，可以参考上篇文章中的主机处理流程����,�ж�。
IOC告警IOC告警事件大多是由内部安全设备发现，通常都是由于内网主机非法请求了高危的威胁情报地址。
这类事件首先应该对IOC告警进行确认，在微步上查询对应IoC，如www.iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com
看到以上结果，基本确认内网是存在WannaCry蠕虫病毒，有NTA的情况下基本能快速定位所有感染主机，处理方案参考上篇文章的勒索病毒处理流程。
如为其他告警但是确认为恶意安全事件的，也可以通过搜索引擎查询对应的分析文章，根据病毒行为作出对应的修复和后续的防护措施。
特殊情况下，如果IoC告警大概率确认为恶意，但是也无法找到相关文章，需要人工进行分析。
windows下通过netstat -ano命令来查看请求对应的IoC的PID，然后使用tasklist /svc|findstr “PID”来定位到对应进程。
linux下操作思路与以上类似，不多赘述。另外如进程请求变化太快不好定位，推荐个大佬写的小工具可以试试。
APT事件此类事件本人接触的并不多，实际遭遇目前差不多就两三次的样子。首先明确一下什么样的事件可以被归类为APT事件，借鉴一下百度百科的说明，APT***的主要特征有针对性强、组织严密、持续时间长、高隐蔽性和间接***。详细可以参考百度百科。
简单讲述一下本人遭遇过的一个事件为例，接到应急通知，某军工相关单位，更新了软件后安全设备一直告警。
到现场查看，杀软当前更新到最新版本，扫描到的***日期在两年之前，此前一直没有发现（环境为内网环境，无法连接外网，近期才更新了杀软病毒库）（持续性），说明***具有一定的免杀性（隐蔽性），考虑到目标系统在内网（间接***）并且为敏感单位（针对性），基本确认为APT事件。
由于时间太久远，网站没有日志记录，通过沟通确认网站使用了某知名OA系统，查看webshell时间与当年该OA系统爆出RCE漏洞时间基本吻合，大致确认是由于该漏洞导致的***，由此得出结论，鉴于事件性质，后续工作移交了对应部门进行处理。
总得来说，如果真怀疑遇到了APT，还是建议找专业公司来进行解决。
总结文章总结了应急过程中常见的情景，以及对应的处理方式，更偏向于刚接触应急的朋友进行参考，文中若有不对还请指正，希望本文能有所帮助。
*本文作者：3unshine，转载请注明来自FreeBuf.COM