Question

网络安全涉及面非常广，有一些基础的安全加固配置，比如交换机上启用 port-security、BPDU-Guard 等防护机制，对未使用的接口默认全 shutdown，使用 AAA 认证技术，防火墙上开启默认 any any drop 策略等；也有一些专门的技术或解决方案，如 NGFW、NIDS 等。

企业在划分了安全域后，不同域之间需要通过 VLAN、ACL、防火墙等技术进行隔离。而安全域控制仅能依照安全策略进行部署实施，但是即使符合安全策略的网络访问，仍可能存在恶意的网络访问行为。同时，安全策略在不断运营调整过程中，也可能存在失效的情况，如何及时发现这种隔离失效也是一个问题。因此，针对上面这两种情况，我们应能具备一定的检测甚至阻断的能力。常规思路是在实施网络隔离（VLAN、NACL、防火墙等）外，还需要对其进行流量分析（基于特征的 NIDS、基于黑白名单及模型的异常访问检测系统等），以便发现异常。除了被动检测外，还可以主动扫描，以发现 ACL 失效的情况。另外，在网络中适当地部署蜜罐，也能发现一些恶意行为，甚至包括同一个安全域内的恶意行为。蜜罐可部署在终端上，也可以部署在后台服务器上，用来发现网络上的扫描、探测等行为，我们将在 13.7 节中阐述。

13.3.1　网络入侵检测系统

网络入侵检测系统，无论开源还是商业都有不错的选择。Snort 是一个具有代表性的开源 NIDS，网上也有较多的中文资料和配套的辅助工具，如 SnortSnarf、ACID 等。开源 IDS 除 Snort 外，还有 Bro 可选，Bro 事件生成引擎中实现的应用层协议功能比 Snort 多，并且提供用于对事件做深入分析的策略脚本。开源的缺点是相对麻烦，先要对其有深入的理解，然后再学习其语法定制相应的规则，对安全人员的要求较高。在安全人员能力和数量有限的企业里，还是建议使用商业产品，性能是个很大的优势，商业产品的支持会比使用开源方案更有保障；如果需要满足特定场景而定制规则，商业产品也可以进行定制；产生安全事件后，商业产品还会保留对应的数据包以供进一步分析。例如，内网渗透常用的 PsExec 工具，首先防病毒一般不会查杀，因为它是 Sysinternals 系列的一个工具，但如果我们需要发现这种行为，可以在终端上检测 PsExec 进程的运行（进程可以改名，MD5 也会随着版本不同而不同），也可以在目标机器上检测 PSEXESVC 服务的创建（服务名在高版本的 PsExec 里可以用户指定），还可以在网络上使用特征进行匹配。

当然，具体到这一个特征，很容易规避，甚至新版 PsExec 直接提供了-r 参数让用户自定义。一般的做法是通过各种测试分析数据包，提取最稳定的特征，或者多取一些特征，比如流量中返回的一些版权或说明（如 Execute Processes remotely），或者直接在 SMB 协议中看是否返回一些 shell 提示符等，具体就不再展开讲了。

在实际的运营过程中，需要关注流量镜像是否有效，流量是否缺失，自动化的验证事件是否正常触发等。

13.3.2　异常访问检测系统

有些请求不会匹配 IDS 策略，比如从分支机构远程桌面访问总部的一台机器，看似一个正常的登录操作，但可能违反了企业内部安全策略，这时候可以借助异常访问检测系统进行检测。

基于黑白名单策略及模型的异常访问检测系统就是一个例子。基于黑白名单策略好理解，比如不允许办公前台网段直接远程桌面或 SSH 登录到办公后台服务器网段，除了应急需要保留几个固定的 IP 之外，需要设置一个白名单和黑名单。

除了传统的黑白名单策略外，分析网络访问上的异常还有两个切入点：

·基于访问路径的异常。比如，历史上 A 和 B 经常访问 C 的 1433 端口，突然有一天 D 也来访问 C 的 1433 端口，这在历史记录中是从来没有的，因此就算一个访问路径上的异常。

·基于访问频率的异常。比如加入域的办公电脑每天访问域进行认证的次数为个位数，突然某天一个 IP 不断地向域进行认证尝试，超过我们系统设置或者学习到的阈值，这就算一个访问频率的异常。

拿到网络流量后，我们按时间、源 IP、源端口、目标 IP、目标端口、应用协议这六个元素来标识访问关系及统计访问频率，通过自学习模式生成白名单和 profile 规则，按照我们的管控规则自定义黑名单，对后续流量按照白名单、黑名单、profile 规则的顺序进行匹配，对高风险事件进行实时告警。系统的处理逻辑如图 13-2 所示。

图 13-2　异常访问检测架构

频度分析在黑白名单策略匹配之前进行，频度是针对所有的事件进行分析，先通过设置阈值来定义频度，当超过阈值时会产生相应的频度异常告警事件；同时事件会继续经过白名单、黑名单、profile 的处理引擎，命中白名单的忽略，命中黑名单的产生异常流量告警事件，命中 profile 的忽略，未命中 profile 的则会产生未知流量预警事件。在实际的黑白名单策略设置过程中，主要考虑以下三类情况：

·跨区域的访问，比如，办公网和业务网之间的访问，总部与分行之间的访问，无线网段与办公网段之间的访问，内网与外联单位之间的访问，DMZ 区域主动外连访问等。

·重点资产的监控，比如，域控、补丁升级服务器、堡垒机、网络设备、重要领导电脑、大数据平台、征信系统等针对性的策略。

·特殊协议监控，比如，远程桌面运行在非 3389 端口，SSH 协议运行在非 22 端口，内网 PPTP、L2TP、VNC、PCAnywhere 等协议运行在网络上等。

13.3.3　隐蔽信道检测系统

除了上面讲到的几个点，还有一个不可回避的问题，就是隐蔽信道的检测与阻断。很多企业在防火墙上对 Ping、DNS 都是不做限制的，甚至个人 PC 及后台服务器均能 Ping 通互联网，如图 13-3 中路径①所示。

图 13-3　DNS Tunnel 与 Ping Tunnel

图 13-3 中，路径①存在一定的风险，黑客能通过 ICMP 协议的缺陷，将需要窃取的数据分片封装到 ICMP 协议的 Payload 中，通过不断地发送 Ping 包，窃取信息。同样原理，图 13-3 中的路径②，黑客也可能利用 DNS 协议的缺陷，将需要窃取的数据分片封装到 DNS 协议的 Payload 中，通过不断地发送 DNS 请求，窃取信息。

ICMP 协议格式如下：

DNS 协议格式如下：

针对此类问题，建议的解决方案如下：

1）在 IDS、IPS 上检测异常的 ICMP、DNS 协议包。此种方式的有效性依赖于特征库。针对黑客常用的工具进行研究分析，定制出特征库是一个方法，比如 PTunnel 代码里就有个 magic，如图 13-4 所示。

图 13-4　PTunnel Magic Code

如果命中 0xD5200880 这个特征的 ICMP 包，肯定有问题。当然，如果黑客修改这个 magic 值再编译就不行了，还得继续找其他的特征。

2）监控数据包的发送频率。对于 ICMP 协议，正常业务场景下不会持续不断地发送 Ping 数据包，如果发现有短时间内不断发送 Ping 包请求的，都可以作为可疑事件进行排查。由于终端上 DNS 请求数据包较多，而且每个用户的使用习惯不同，此方法不适用于 DNS Tunnel 的检测。

3）异常包大小检测。对于 ICMP 协议，在 Windows 操作系统中默认包大小为 32 字节，SUSE Linux 操作系统中默认包大小为 56 字节。其最大数据包大小遵循 IP 协议规定，为 65500 字节。可以在防火墙上设置一个 ICMP 数据包大小的阀值，超过的 ICMP 包直接丢弃并报警。在 RFC 1035 中，对于 DNS 的 UDP 数据包原始大小做了限制，但可通过 DNS 的扩展名机制（EDNS0），允许 DNS 请求者公布其 UDP 数据包的大小，并且传输大于 512 字节的数据包。黑客也常利用此方式，将需要窃取的数据封装到 DNS 大数据包中。因此，可以在防火墙上针对 DNS 的 UDP 长度大于 512 或 TCP 包长度大于 1024 的约定进行丢弃并报警。

4）防火墙上只允许 DNS 请求到外网指定的 DNS 服务器，比如省 localDNS 或者 114.114.114.114；有条件的企业还可以针对 DNS 协议中的 TXT 和 NULL 类型的记录进行阻断。注意有些场景也需要使用 TXT 记录，比如邮件方面会用到 SPF 等，有些厂商查询情报也用此方法。

以上各种手段有一定的效果，但无法完全阻拦有耐心的黑客。一些企业开始将目光放到大数据、机器学习方面，通过对 DNS、ICMP 请求使用各种模型进行分析，以期发现异常。机器学习需要大量的日志样本，目前此类方案在企业实际环境中的效果有待观察。