今年是去了中铁下面一个子公司，加上我总共俩人，所以人手还是比较紧张的，上设备，监控，应急，研判，溯源都是我俩在做，虽然没出什么较大的事情，但是也是出现了很多突发情况和应急问题。

主要是来介绍一下护网中遇到的类似的应急以及一些突发时间以及护网中常见的流量如何去鉴别正常业务和攻击流量

PS: 文中图片均来自网络，虚拟环境中进行测试，不存在实际环境，如存在侵权行为联系作者删除，万分感谢

研判

其实研判主要就是考验你对流量的判断力，总体来说防火墙误拦和sip误判还是有很多的，几乎是触碰到规则就会被拦截，比如匹配到&start会直接拦截并且报代码注入，其实很多正常业务都会带有这个字段等等，下面我会用一些图片结合文字简单说一下。

0x01

这个数据包虽然sip报警，但是从返回包以及请求包中的username和password来看，是一个公司人员来请求上网认证的这么一个数据包，是正常流量，就可以不去予以关注，只是触碰到了sip的规则。

0x02

这条数据包sip报的是SQL注入，可以看到数据包中确实带有SQL语句的特征，convert(varchr(100),vahdat,111)，但是综合这个数据包的请求体以及返回包来看，并无其他特征信息指向这是SQL注入，只是命中了sip的规则，也是误报

0x03

这个就没啥好说的了，很明显的SQL注入攻击行为，封IP就完事，能溯源就溯源。

0x04

护网中如果见到带这种**spider的，一般都是爬虫工具，直接封掉IP就完事。

0x05

下面这个是我所在单位遇到的一个数据包，乍一看好像没啥问题，但是仔细一看，问题大了，很明显的一个攻击行为，而且还是我们内网一个服务器发给另一个服务器的，这就有点可怕了，首先就先断开这太服务器的所有网络通讯，上去排查即可。

0x06

这个虽然并无攻击行为，但是很明显看到返回包返回了报错信息，那么这危险就大了，如果被攻击者发现利用，造成后果不堪设想，所以遇到这类情况，需要第一时间报给客户并且沟通，如果客户同意先停掉这个服务，那就先停掉进行处理；如果这个业务不能停，那么就重点关注一下这个业务系统，尽量出现情况第一时间处理。

关于流量的研判的话就介绍到这里，其实研判还是需要根据平时经验来进行研判即可。

应急

关于应急，今年护网只出现了两次，其他情况好像没怎么遇到过，不过记录意义还是很强的，简单记录一下应急的思路。

Windows server

其实感觉应急还是比较简单的，更考验的是你的心态、思路、以及经验。

第一个遇到的是因为cwpp突然发现内网一台服务器突然暴力破解内网另一台服务器，这种情况之前从未遇到过，于是第一时间将这台服务器做断网处理。接下来便是去排查处理。

远程到服务器后，突然发现桌面上多了一个login的文件，创建时间是7.26，正好是护网期间，但是这一天运维因为服务异常停了的原因，登过这台服务器，但是他也记不清有没有这个文件了，里面信息还、是登陆成功的信息，本着小心使得万年船的态度，我就上去看看

事件查看器——Windows日志——安全，发现日志并没有什么异常登陆信息或者大量登陆失败信息，那日志这方面就是正常的了。

下一步就直接去排查用户之类的东西，看看是否有隐藏用户或者不是客户建立的用户，如果有就说明被进去了，net user查看用户信息，但是不会显示隐藏用户。

隐藏用户就需要用别的办法去看，通过改注册表的方式，详见下图

翻了翻隐藏用户，也一切正常，那么大概率不是攻击者了，不过还是做一下后续的处理为上。

下一步就是去看服务的日志了，这台服务器开着tomcat和iis，就直接去翻这俩的日志，7.26好前后并未有什么异常的日志，到了这里，大概确定这台服务器是安全的了。

后续就是D盾扫了tomcat和iis的目录，虽然在tomcat目录下面扫出来了俩后门，但是看创建日期都是护网之前的，大概率不是红队，删了就ok。

那么这次应急就结束了，平安无事最好，也算是闹了个乌龙，应该是运维登上去生成的，

Linux

这次的是一台centos的系统，巧合是我的云服务器也是centos，这次是因为sip报了挖矿，虽然挖矿肯定不是红队，但是万一被检测到，也扣分，还是上去把这个挖矿给找出来删了把

第一时间直接断网，然后xsehll ssh连上去，挖矿还是比较好找的

直接top命令，输入P按cpu排序，输入M就按内存排序，我一输，那个挖矿差点直接直接拉满，太明显了有点。下图是我自己的服务器，只是让大家看看效果。

然后直接去找那个你想找的进程对应的exe即可，ls -al /proc/[pid]/exe，比如我这里想看pid=1940的，直接ls -al /proc/2940/exe即可

然后找到后，rm -f xxx.exe删除即可，这里挖矿的应急基本上就结束了。

本着认真负责的态度，还是去仔细的排查一下吧，顺便跟大家说说应急需要排查的一些东西，想到啥说啥，可能不全，大家理解一下。

日志的话肯定要看的，Linux的日志全部在/var/log下面，具体的大家可以自行百度。

1、开放的端口，

netstat -ntpl，我就不截图了，如果有开放的端口可疑，那么就去看看对应的进程，比如想看22端口，lsof -i:22

2、当前服务器的一些进程，

ps -aux，有四种状态，S(休眠)，R(正在运行)，D(不可中断)，T(已停止)

当前服务器的守护进程：ps -ef | grep inetd；查看隐藏进程：ps -ef | awk ‘{print}’ | sort -n | uniq >1 ；

3、服务查看

systemctl | grep -E "\.service.\*running"；如果想只显示服务名的话，systemctl | grep -E "\.service.\*running" | awk -F. '{ print $1 }'；

4、文件检查

文件检查的话，可以根据上面的一些信息去对应查找，看文件夹下面文件修改时间的话，ls -alt 文件夹名，然后如果需要的话，去查看其他重点文件的是否被修改，如DNS配置文件、HOSTS文件等

DNS配置文件：cat /etc/resolv.conf
HOSTS文件：cat /etc/hosts

• 敏感目录的文件分析

如：/tmp目录，/root、/boot、/bin、/usr/bin、/usr/sbin、/sbin

• 查看tmp目录下的文件，按照时间的排序：ls -alt /tmp/

• 使用 stat命令查看具体时间

• 针对可疑文件可以使用stat进行创建修改时间、访问时间的详细查看，若修改时间距离事件日期接近，有线

性关联，说明可能被篡改或者其他

其他我就不多说了，启动项计划任务等等，大家可以去百度收集一下，很全面。

溯源

这次护网溯源是一次都没遇到，溯源是可遇不可求，这个倒也无所谓了，反正也算较为圆满吧。

最终结果

本次护网所在单位也是圆满结束，由于所在为集团下属分公司且所作措施非常严密，所以结果相对圆满，集团就没有那么幸运了，来自各个二级单位的横向属于是把集团打的头都晕了。