如何应对专线攻击；总部与分支机构的安全责任划分 | FB甲方群话题讨论

码农的梦想

2024-05-17 14:57

短信预约 -IT技能 免费直播动态提醒

各位 Buffer 晚上好，FreeBuf 甲方群话题讨论第 235期来了！FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论，Kiki 群助手每周整理精华、干货讨论内容，为您提供一手价值信息。

话题抢先看

1. 通过流量检测设备发现专线的攻击流量，只能定位到统一出口的IP，无法找到具体对应的攻击源，应该如何处置？
2. 如果通过主机检测发现专线访问某应用的攻击是加密流量，应该如何排查和整改？
3. 支持机构到总部生产内网的业务访问，往往直接互通，缺乏访问控制，应该如何防护？
4. 因总部受攻击而造成分支机构失陷、或因分支机构受攻击造成总部的损失，大家是如何划分总部与分支安全责任的？

某集团企业存在多种专线接入总部的情况。目前有分支机构机房与办公终端接入、远程移动办公接入（SSL-VPN）、还有第三方机构公用接入等。

Q：通过流量检测设备发现专线的攻击流量，只能定位到统一出口的IP，无法找到具体对应的攻击源，应该如何处置？

A1：

这属于部署检查设备的位置有问题，办公从专线访问都没有点对点防火墙策略。

A2：

上更强大的检测设备或者安全策略。

A3：

加WAF，在专线前面使劲堆安全设备。

A4：

这种场景尽量不要做NAT。如果不得已一定做NAT，就记录NAT日志，准备一个地址池，一对一映射，能查得到。

A5：

主要是双向转换在防火墙上配置单向。

A6：

1. 减少出口数量；保留的出口部署态势感知系统，提高溯源能力。
2. 区域间设置防火墙，端口最小化。

A7：

1. 如果不涉及与外部机构的通信，能不做NAT就不要做NAT，做NAT就会涉及溯源与封禁的问题，非常麻烦，不是好的解决方案;
2、如果是与第三方机构对接，需要做双向转换，或者其它不得已的需求，一定要做，可以准备个地址池，不做端口复用，一地址对一地址，记录日志，方便溯源。
3、如果是Http流量，插XXF。

A8：

从长远的角度，可以考虑每个设备一个内网IP，私网地址不够用，可以评估一下，考虑抠一段国外互联网地址放在内网使用。
有NAT等共用IP的节点，考虑加上访问日志的记录，不说是长期记录，最起码是可以临时记录一下，否则就只能抓包了。

A9：

这明显是一个网络问题，不要做NAT，分配一个内网地址段给VPN用就解决这个问题了。

A10：

有一些接入方式是可以改造的，比如VPN这种，直接分配虚拟IP的话，就可以建立一对一的关系对应到人。有一些政务线会在子单位网络出口放个探针，这样就可以直接从子单位出口抓内网IP的告警。另外有一些实在无法溯源的，就是从流量内容里分析了，分析Session里的身份信息之类的。

A11：

纵深防御不应该多层次、多节点部署安全检测能力么？

A12：

设备部署在哪里都无法看到对方出口过来的内部地址啊，除了VPN，都需要在对方部署设备才行。

A13：

确实，除非搞分布式的检测系统进行统一监测。

A14：

所以要点对点防火墙策略，映射转换的时候写的细一点。

A15：

现在网络取证技术很成熟完善收集和分析相关的网络数据包、日志和系统信息，可以追溯源头。

A16：

内部流量监控，在内部网络中部署流量监控设备，实时监控内部流量，以便在检测到攻击流量时，能够快速定位到具体的攻击源。

A17：

现在流量监控设备都只能监控未加密的流量，加密的基本上无解。

A18：

各分支机房有啥日志类设备吗？通过时间戳排查不知道能不能缩小下范围。加密的只能靠情报了。

A19：

临时在出口设备上接一个流量监测，或者做一个流量镜像，再看流量中是否有相符的攻击流量。之前遇到过类似的情况，但终端数量不大，当时是这样解决的。

A20：

之前玩过一套安全网关，操作就是把证书卸载的操作上提到F5上面，但是这个只能解决自己系统的加密流量问题，监测自己系统的安全性。

A21：

我们的方案比较复杂，费钱。子公司配备下一代防火墙+上网行为管理+准入+DLP+终端杀毒+SDWAN；
总部架构是下一代防火墙主机+上网行为管理+准入+DLP+终端+SDWAN主节点，还有边界防火墙对接。

Q：如果通过主机检测发现专线访问某应用的攻击是加密流量，应该如何排查和整改？

A21：

看主机检测触发的规则排查。

A22：

应用证书提供给流量检测设备，一般能解密加密流量。

A23：

内网可以考虑证书卸载，卸载不了的加密就在应用服务器上分析日志看看了，还有就是可以对一下TCP随机的源端口号、序列号等信息。

A24：

网络规划设计的时候一般要求在出口或Ngnix做统一加解密，那样内部的流量都是透明的，没有的话就需要主机防护软件，类似XDR。

A25：

如果是外部访问内部主机的WEB应用，上WAF之类的安全设备解密；如果是内部主机外访Https，只能查下目标的威胁情报了，或者判断域名/IP归属位置是否符合业务通信逻辑了，感觉只能这样。

Q：支持机构到总部生产内网的业务访问，往往直接互通，缺乏访问控制，应该如何防护？

A26：

分支机构必须要过防火墙的，而且严格限制了访问范围。

A27：

1. 要求分支机构严控访问IP；
2. 总部把分支机构过来流量进行汇总监测；
3. 总部针对分支机构访问IP做策略限制。

A28：

VPN+堡垒机，控制分发VPN账号和堡垒机账号。

A29：

上面这个对外友好点。

A30：

梳理好策略，像SSH、RDP、MySQL等高危应用应该做到精细化管理，白名单机制。正常WEB业务这个全通感觉还OK。

Q：因总部受攻击而造成分支机构失陷、或因分支机构受攻击造成总部的损失，大家是如何划分总部与分支安全责任的？

A31：

责任不好说，还是要看具体情况。

A32：

专线接口是边界，无边界，既无责任，边界是责任划分的基础。

A33：

这种情况自己边界安全做好、各管自己一个安全域、流量全审计分析。

A34：

只要是沦陷了，不管何种原因，都是防护不到位，都有责任。

A35：

讲道理，你这个分支结构跟总部看起来不算事从属关系啊，并列关系的话，全部当作合作方，别一个公司了。

A36：

从属一般看企业政策，合作关系以合同协定为准。

A37：

如果纯从技术方面考量，两边肯定都是有锅的，从那边的进入的，为什么对来自总部/分支机构的攻击没有检测/拦截；但是最后肯定还得看实际的损失情况，和跟负责的领导关系来分锅。另外也得看是技术问题还是管理问题。

A38：

这也存在一个视角问题，整个集团内，肯定是下面的某个组织的责任。但是放到全国或全世界，那么就是你集团总部的责任，总不能跨过你总部，去追责下面的分公司，这逻辑不通。

A39：

这个分析的透彻，确实是从不同视角来看，我们应该是在内部视角来看问题责任。

A40：

主体责任要划分清楚，统一要求分支机构配备安全负责人、安全技术人员（可兼职）。我们这边各分支机构出一个人，总部培训后，定期分支机构相互审计。

本周话题总结

本期话题讨论了专线和远程接入安全相关的话题。在处理专线攻击流量时，关键在于部署检测设备的位置，加强安全策略，避免NAT等操作，并考虑加强防火墙策略、流量监控、溯源能力等。对于加密流量攻击，建议提供证书给流量检测设备解密，或在应用服务器上分析日志。在支持机构到总部生产内网的业务访问时，建议严格控制访问IP，限制访问范围，采用VPN和堡垒机等措施。在划分总部与分支安全责任时，应根据具体情况、企业政策和合同协定来确定责任，同时加强内部安全培训和相互审计。主体责任要划分清晰，确保各分支机构配备安全负责人和技术人员，定期进行相互审计以确保整体安全。

近期群内答疑解惑

Q：终端的数据怎么远程擦除用什么工具？

A1：
IPG、Macfee 之类的加密系统有些支持，微软Intune，还有各种MDM。
A2：
IPG可以擦除？
A3：
不可逆的加密等同于擦除。
A4：
我记得IPG的加密密钥可做不到一个设备一个密钥吧。
A5：
都是MDM的功能，远程锁定，擦除。Mac是Jamf，贵得很但可以这么弄，Win不太了解了。

Q：对于软件成分分析这种工具扫描出来的组件版本问题，某些组件不能升级的话需要怎么处理？

A1：
我们现在的处理方式是加白打标，方便后期梳理。
A2：
风险怎么处理呢？
A3：
有压制办法或者缓冲手段吗？大不了就接受。
A4：
现在就是想问怎么压制或者缓冲。
A5：
我觉得说到底就是找签字背锅的，加白打表感觉也是这个意思，这个如果动某些组件会影响到现网业务情况，只能向上管理。
A6：
我的战略是有些可以用户输入侧强管控，但是适用范围不是很大的样子。
A7：
具体问题具体分析吧，感觉也不是每一个都是一样的。无非就是让其无法利用，利用程度有限，利用成功也能降低影响这几个维度。

Q：Windows服务器很多漏洞修复，补丁打上去之后需要重启，但是业务不让重启，这该怎么弄？

A1：
注销当前用户，重新启动Server服务。
A2：
做一下变更流程。打补丁理论上要过一个变更的流程，包括评估和测试，把重启作为其中一环加进去就行。
A3：
现在就是怕起不来，有些数据库服务器重启半个小时直接就是P0事件了。
A4：
你们都那么勇的吗，生产业务的OS直接敢打补丁，还要重启。
A5：
变更流程要有的，评估、测试都要有，不然补丁出事你也就凉了。
A6：
不打补丁不一定凉，但是补丁出事一定凉。
A7：
做安全很多操作真的是如履薄冰，我现在干很多事都得再三确认，甚至在自己的服务器上模拟一遍操作。你这个顺手一按修复，属实有点容易出事。