2022年10月18日23:00:39评论394 views字数 5484阅读18分16秒阅读模式

坚持了14天的夜班，虽然同时负责监控和封禁，晚上并没有太大的工作量，见的大多数都是国外地址的一些公网扫描行为，少有针对单个业务系统的异常流量，炫了大量的零食，趁着最后记录一下这段时间的见闻。整篇内容基于个人观点，出于保密会大致略过一些内容，不足之处欢迎指出。

都见到了哪些攻击

type I: Mozi(墨子僵尸网络)和与其类似的僵尸网络

这类告警一般直接封禁没有上报，针对性利用一些路由器、IOT设备漏洞尝试下载脚本并执行，忙起来甚至都懒得封，这么离谱的payload应该不会拦不到吧。

参考资料：

墨子僵尸网络分析

https://blog.knownsec.com/2020/11/%e4%b8%93%e9%a1%b9%e8%a1%8c%e5%8a%a8%e7%9a%84%e6%84%8f%e5%a4%96%e6%94%b6%e8%8e%b7-2020-%e5%b9%b4-9-%e6%9c%88%e5%a2%a8%e5%ad%90%ef%bc%88mozi%ef%bc%89%e5%83%b5%e5%b0%b8%e7%bd%91/

type II: 端口、目录扫描、口令爆破等

端口和口令爆破一般安全设备可以产生告警，例如一段时间连续访问多个端口或者产生多次认证失败的结果就会判断为相应的事件，此类告警有一定误报的可能。针对目录扫描一些设备会根据http响应码来判断，例如一定时间内返回404和200的比例异常，也可以通过访问的URI来判断，例如正常业务不会直接访问到的敏感目录或者文件，例如/phpmyadmin、wwwroot.zip、/.env等等。

type III: 漏洞利用

除了目录的扫描，还会看到大量验证SQL注入点、目录穿越、尝试struts2或log4j等中间件/组件或商业系统已知高风险漏洞等等的告警，此类告警不一定是由红队造成的，可能是一些黑产在公网利用工具扫描。这类攻击可以先临时封禁IP，通过响应码或者是否可能存在相关漏洞初步判断是否利用成功，例如对java系统尝试php相关漏洞、对linux系统尝试windows漏洞，可以考虑忽略部分告警减少攻击流量过多时的工作量，但是这样的前提是对业务系统足够熟悉。

如果只是使用工具无差别扫描，发现并封禁及时的话可能攻击者并扫描不出太多内容，让我比较担心的是有目的性的针对某个服务器页面，或者针对整个业务系统尝试漏洞，例如手工测试注入点、反序列化、log4j等，或许看到的告警都是没有成功的，但很难确认是否有安全设备遗漏的内容。

type IV:僵尸主机类

经常会看到内网会出现一些挖矿相关域名的DNS请求，或者横向尝试MS17-010(永恒之蓝)等等。

type V:webshell连接

其实不管是上传webshell本身还是通过菜刀、冰蝎这类程序与webshell进行通讯，大多数情况下还是具备一定的文件或者流量特征，对于加密的冰蝎好像没有什么特别有效的手段，但是出现连接webshell的告警基本等于这个资产已经极度危险了。

type VI:钓鱼邮件

似乎今年有不少的钓鱼邮件，这方面一是加强终端的安全和企业员工的安全意识培养，二是要能及时发现内外网异常通讯的情况。

值得记录的东西

事件处理流程

今年现场的攻击来源有两大块，互联网和与子公司的专线，考虑到可能的风险，这里仅大致记录互联网区域出现告警的处理流程：

出现一条告警时，需要监测人员先对告警进行初步判断，通过请求或者返回的内容判断是否为误报，是否利用成功，明显未成功但确认是攻击的需要封禁IP，判断会有影响或者无法确认时需要提交给研判人员进行判断，研判可以通过调取流量或者其他方式来给出判断结果和处置的建议，确认是攻击且利用成功的话需要和业务方确认处置方案，并且交由溯源和应急处置人员后续处理，最终处理完成后形成报告上交。

在整个护网阶段，听到客户和二客户嚷的最多的就是闭环，我个人的理解是整个流程要环环相扣，每个环节负责的人都要有反馈，在现场这个“闭环”主要依托于一个工单系统，监测人员进行上报，研判和处置后续依次给出意见，再由专人根据意见来进行后续对接处理，想法很好，但是这个工单系统做的实在是有点烂。还有一个点，就是现场地址的封禁是交给监测人员来做的，也就意味着监测的人员不但要盯着告警，上交工单提供截图等信息，还要留意处理意见，还要及时的封禁IP并做好记录，当攻击流量变多的时候封完地址估计告警已经刷好几页了，闭环是事件的闭环，又不是人员的闭环。

怎样的的防御体系

出口的防火墙、WAF和IPS，是应对攻击的第一道防线，也是能直接阻断请求的设备，一些很明显的攻击行为会被WAF和IPS直接截掉，奇怪的是不知道客户出于什么考虑，将WAF和IPS部署在了防火墙之上，这一点也给后续监测流量造成了一些影响，这一点后面会再提。
内外网各区域重点的交换机均镜像了流量到旁路的安全设备，这部分一是为了处理未被出口设备发现的攻击，二是为了检测到横向流量是否正常。
在服务器区部署蜜罐，蜜罐地址虽然和正常业务服务器在同一段，但是并没有对用户公开，因此访问甚至是对蜜罐尝试进行探测、攻击的流量一定是存在问题的，不但能通过蜜罐捕捉到攻击者的地址观察其攻击行为，也有一些反制的功能。
服务器上部署了终端软件，可以监控服务器异常的用户、进程、文件等内容。
还有一个没用到但我觉得有点用的技术：防篡改，针对重要的目录或者文件也可以考虑采用该技术，目前见过的有两种实现方式，一是通过实时监测防护文件的hash值，如果发现有变化的话及时恢复，二是通过系统安装软件控制某个目录或者文件没有修改的权限，支持进程/用户白名单，技术细节不详。

被攻击的经历

不能说红队夜里搞偷袭，不讲武德。

一个乌龙事件-IPIP隧道

某天半夜，负责监控科来流量分析的小伙伴发现了子公司发往自己内部的攻击流量，流量中攻击特征十分明显，再一看IP地址确实也是分配给子公司的IP，上报上去之后发现有个地方解释不通，部署的各种监测设备采集的都是集团内部的流量，并没有在子公司部署探针，于是第一次发现当作误报给忽略了，后来第二天第三天还是能看到这样的流量，仔细点开一条TCP报文发现有两层的IP报文，第一层协议号为4(IPIP)，第二层协议号才是实际的传输协议，代表这些是经过IPIP隧道封装后的流量。举个例子，A和B是两台服务器，服务器各自又起了一堆虚拟机，但是只给物理机分配了一个IP地址，如果我想两个服务器起的虚拟机可以通讯的话，就可以在A、B上建立IPIP隧道，将虚拟机的子网互相访问的流量承载于A和B这两个地址，这样就不用局限于地址的数量，地址段也可以随意设置。效果如下图，来源互联网：

2022年HVV总结与思考

后续经过排查，业务方反馈是一些容器通过这个隧道进行交互，看到的攻击特征实际是同步的日志中的内容。但是这样就引入了一个新的问题，对于一些流量分析设备，包括wireshark会将隧道封装前的地址作为通讯的源、目的地址，也即上述举例中的虚拟机地址。通过测试，并不需要多张网卡或者实际建立虚拟机，只需要在物理网卡上再添加一个IP即可实现这种流量的伪装，所以有没有这样一种可能，通过这样或者类似的技术，在一定程度上能对安全设备进行欺骗，导致在攻击者内网横向渗透的过程时设备识别不到正确的IP地址。

奇怪的封IP姿势

有些情况下会发现在监测设备上直观的看不到攻击者的IP，这样情况下一般是通过了代理导致，但是根据不同的代理使用场景，判断攻击者真实IP的方法也有所不同。

负载在内网：这时在内网流量中会看到攻击告警是内网地址到内网地址，这时候只需要查看流量中的xff信息即可看到正确的攻击者ip，如果有多个，一般最后一个地址是到负载的地址，前面的则是到内网之前的其他代理记录的IP或者被伪造的地址。这种情况可以直接在出口设备上封禁掉xff中的地址，如果不是下文2中的情况，多个地址可以全封掉。
负载在公网：一般出现在流量经过CDN或者云防之类的场景，这样会导致进入内网的源地址是公网地址但不是真实地址，要在xff中获取。这种情况下只能根据xff进行封禁，一般防火墙不提供这样的功能，只有一些7层的安全设备例如WAF、负载等有这种功能。
通过代理：如果是一个明确没有经过任何负载的业务看到了带着xff头的请求，一般来说不能直接判断xff中的地址就是真实地址，因为xff是HTTP的一个拓展头部，是可以被伪造的，对于一些安全设备来说，会默认将xff中的地址作为真实地址，攻击者也可以利用这个特性来欺骗安全设备。这种情况下如果无法判断哪个才是真的，就建议把两个都封掉。

顺便再提及一下上文提过的拓扑中WAF在出口防火墙之外的情况，一般情况下这样也是没有问题的，不同的应用有不同的IP，在出口内和外一般而已只是看到的目的地址是公网地址还是内网地址的区别，但是在现场遇到了一个奇怪的现象，访问某些业务的请求发现有攻击后，在防火墙上封禁了对方地址后还能在waf上看到http请求，通过抓包发现请求确实到了防火墙。这就不符合常理了，防火墙封禁后应该是不能和服务器建立tcp连接的，也更不会有后面http请求，后续发现这些业务都是过了云防的，云防探测业务存活的话会先和请求方建立连接，然后再转发http请求，起到代理的作用，到这个时候请求才会被防火墙阻断，在这种情况下就会看到明明是被防火墙阻断了的地址，还是能在waf上看到记录，如果把waf放到出口内，就能避免掉这种情况。7层的安全防护会引起奇奇怪怪的问题，在使用上一定要有所考量。

一些想法

安全设备应当起什么作用

经常能看到客户会问，有了安全设备为什么还是被攻击了，首先在我看来，安全设备终究是一台设备，在整个安全建设中起到的是辅助作用，负责安全的人做了什么才是最重要的，在攻防之前应该整体考虑一下加固，例如修复漏洞、整改弱口令、细化防护墙策略等等，这类整改可以参照等保关于基线的要求，以后我成大佬了再单独写一篇。

大多数的应用层安全产品都是基于黑名单来做的，也即你的流量或者载荷中包含了某个特征的内容，我会把你当作某一个攻击给记录或者阻断，例如你的请求中包含了sql语句我就会认为你是SQL注入，这样不但面对写的不规范的业务会产生误报，还要面对各种攻击者的绕过手段。

因此不论是串接还是旁路的设备，应该将它作为最后一道防线，并不是买了安全设备或者产品就可以放着一堆漏洞的服务器或者系统不管了。

攻击者使用分布式或者代理池来扫描怎么办

这一点感觉是所有安全设备的一个弱项，以口令爆破为例，对于单个IP多次尝试我可以设置一个阈值，短时间内多次登陆失败可以产生告警，单个IP多次触发告警可以考虑封禁该IP一段时间，但是对于多个IP同时来进行爆破，每个IP只尝试一两次的话，不论是设备还是人都是无法处理的，设备不能判断哪些是有异常的，人也跟不上告警的速度。

有几个思路，但觉得也没那么靠谱，一是要看攻击的流量有没有特征值，例如统一的ua头，可以根据特征来进行封禁，二是根据被重点攻击的URI进行控制，也即如果一个页面被多个地址攻击的话，可以在短时间内根据影响考虑限制其请求数量，在尽量小影响业务的同时及时对攻击的地址进行统计并处置。

设备识别不到的攻击/0day怎么办

这应该是两个差不多的概念，基于特征库(黑名单)来做识别的安全设备一定有它库里没有记录的载荷，略开玩笑的说的话，设备识别不到的都是0day。因此这里的逻辑应该是这样，对于攻击一定是有一个持续的过程，或许是探测或许是已经拿下一台服务器在横向渗透，安全设备没法直接识别的攻击可以寄希望于在其整个攻击过程中会触发其他的告警，这样能有一个预警的作用，例如利用某一个漏洞上传webshell时，虽然利用的漏洞没监测到，但是上传的文件内容、在服务器上进行的操作、对内网进行的扫描都可能会触发告警，所以也就需要在安全建设过程中将各个环境尽可能的都考虑到。

内网横向的攻击怎么办

一般而言，防守的重点都在各个边界，例如出口和各区域之间一般都会有防火墙对访问关系做出严格限制，但是对于单个区域内攻击并没有太多的防御手段，假如一台服务器沦陷，则整个DMZ区域都很危险，如果对该区域没有严格限制的话，甚至会威胁到整个内网。在目前的体系下好像也没有太好的手段，部署服务器终端软件、依靠旁路设备对流量进行分析等等勉强能算作一个解决方案。

需要什么样的安全设备

现在的安全设备很像好多年前的杀毒软件，只需要一个病毒特征库就能工作，因此就会有很多基于判断特征码来进行免杀的手段，很容易被绕过。对于同样的困境，安全产品在检测手段上应该是需要有所突破的，例如之前看到过的百度的OpenRASP(https://rasp.baidu.com/doc/)，不过该方案也有自己的缺陷。虽然提出了问题，但我也没有什么好的思路，攻与防就是这样，期待安全行业以后的发展。

2022年HVV总结与思考