亚马逊AWS官方博客
专利申报中：Infoblox 公司与 Amazon SageMaker 合作，为 DNS 建立一套同形异义词攻击检测模型
本文由Infoblox公司分析架构师 Femi Olumofin 联合参与撰写。
相较于政府颁发的身份证号码或电话号码，我们当然更习惯于通过姓名来识别一个人的身份。同样的，域名系统（DNS）也帮助我们更便捷地通过名称指向并访问对应 IP 地址背后的互联网服务或资源。也正因为DNS本身广泛存在，在网络连接体系中扮演着至关重要的角色，且大多数网络安全策略往往没有做到对 UDP 53 端口的网络流量进行监控——种种原因，导致DNS成为不少恶意攻击者眼中的理想目标。事实上，不少已知的传统安全解决方案确实无法检测到DNS恶意软件中所使用的命令与控制通信（C&C）、数据窃取、Fast Flux与域名生成算法。
过去二十多年当中，Infoblox 公司一直是全球领先的技术与服务供应商，专门负责管理并保护网络核心，具体涵盖 DNS、DHCP 以及IP地址管理（统称为DDI）等领域。目前，已经有超过8000家客户（包括超过三分之一的全球财富五百强企业）使用Infoblox产品建立起可靠的本地、云以及混合网络自动化管理与保护体系。
过去五年以来，Infoblox 公司开始使用 AWS 构建其 SaaS 服务，并帮助客户将其 DDI 体系由本地物理设备扩展至云端。本文将着力阐述Infoblox公司如何使用 Amazon SageMaker 以及其他多项 AWS 服务构建起安全分析服务，借此检测滥用及冒用客户品牌的行为。
为目标客户品牌或域名进行社会工程攻击检测，已经成为企业级安全分析服务中的一大关键需求。DNS 的同形异义词代表的是在主观感知上与实际目标著名高度相似的伪造域名。恶意攻击者会创建同形异义词以模仿高价值域名目标，并借此散播恶意软件、网络钓鱼用户信息或破坏目标的品牌声誉等。对此缺乏戒心的用户往往很难将同形异义词与合法域名区分开来。在某些情况下，二者之间甚至不存在任何肉眼可见的显示区别。
Infoblox 面对的挑战
传统域名由数字、字母及连接符组成，各字符均来自 ASCII 字符编码方案，其中包含128个代码点（即可能的字符）；对于拓展ASCII而言，其代码点数量则扩充至256个。国际化域名（IDN）是指可以使用 Unicode 字符的域名，支持用户在其中使用带有连字或变音符号的拉丁字母（例如é or ü，当然也支持不使用拉丁字母）。IDN 为大部分书面系统及语言提供了广泛的字母选项，并允许您以自己熟悉的语言访问互联网。同样的，随着互联网服务在全球范围内使用规模的不断增长，IDN 成为人们与目标市场轻松建立联系、摆脱语言障碍的理想方法。而为了实现多语种支持，每个 IDN 均以 Punycode 表示，其中包含一组 ASCII 字符。例如，amāzon.com 将被转换为 xn--amzon-gwa.com。接下来，各个 IDN 域名都将被转换为 ASCII 形式以与 DNS 相兼容，从而确定如何将域名转换为正确的目标IP地址。
简而言之，IDN 的意义在于帮助所有人轻松访问互联网。但其同样也招来了欺诈者们的关注，他们试图使用外观相同的某些图形替换掉其中的某些字符，借此将用户重新定向至伪造域名处。这一过程，就被称为同形异义词攻击，其中使用Unicode字符创建出与目标域名难以甚至无法区分的伪造域名。以 paypal.com 为例，他们会将其中的a替换为拉丁文小写字母alpha（‘ɑ’ [U+0251]），即pɑypal.com的形式。乍看起来，二者似乎并无区别，但在仔细检查后，两个“a”明显有所不同。
最常见的异同形异义词构造方法包括：
- 使用 Unicode 字符中的 IDN 同形异义词（例如将「a」替换为「ɑ」）
- 多字母拟形文字（例如用「rn」替换「m」）
- 字符替换（例如用「I」替换「l」）
- Punycode 欺诈（例如，将㿝㿞㿙㿗[.]com编码为xn--kindle[.]com，将䕮䕵䕶䕱[.]com编码为xn—google[.]com）
有趣的是，同形异义词攻击的适用范围并不局限于DNS攻击，还可用于混淆操作系统上的进程名称，帮助回避检测系统乃至构建钓鱼系统。考虑到Infoblox的不少客户都对同形异义词攻击深恶痛绝，技术团队决定使用 Amazon SageMaker 开发出一套基于机器学习（ML）的解决方案。
从业务的角度来看，处理同形异义词攻击往往需要占用组织中大量宝贵的资源。在应对域名伪造与同形异义词攻击方面，一种常见的方法是预先注册数百个可能的品牌同形异义词域名，借此堵住攻击者的后路。遗憾的是，这样的缓解措施只能挡住一小部分攻击者，目标明确的恶意方总能找到具有良好效果的攻击机会。而使用 Infoblox IDN 同形异义词检测器，我们已经在Alexa前50大域名的43个当中观察到IDN同形异义词，同样的情况在金融服务与加密货币域名领域也极为常见。下表展示了其中部分示例。
解决方案
传统同形异义词攻击的解决思路，主要基于字符串距离计算。虽然近年来也出现了部分使用深度学习方法的应对措施，但其主要目标仍是对整个域名进行分类。Infoblox 的方法则是对域名内的各个字符进行标记，借此解决这个令人头痛的难题。标记完成后，Infoblox 使用图像识别技术处理各个字符，这就将 Unicode 字符的处理机制由基于代码点转换为基于字形（或者说视觉形态）。也就是说，代码点将仅构成字符编码术语中代码空间的数字值，不再作为判断字符属性的依据。
凭借这种方法，Infoblox 在区分看似 ASCII 字符的 Unicode 字符方面，获得了高达96.9%的准确率。而且与需要重复进行在线预测的现有深度学习方法不同，Infoblox 的检测流程只需要单次离线预测。其误报比例，也远远低于单纯依赖字符串间距离计算的传统方法。
Infoblox 使用 Amazon SageMaker 构建起两大核心组件：
- 基于CNN分类器的Unicode字符同形异义词离线标识符。该模型能够提取可能存在异常的ASCII字符（例如作为域名中的子集）所对应的图像与标答，并将其输出至Unicode映射。更重要的是，此映射将随每一次Unicode标准发布进行重新构建。
- 通过输入的目标域名列表与DNS流对域名同形异义词进行在线检测，并生成检测结果。
下图为基于这两个组件做检测的全过程。
在此图中，所有字符都渲染为一个28 x 28像素的图像。此外，训练集与测试集中的各个字符，都将与外观最接近的ASCII字符（即其标签）相关联。
在接下来的章节中，我们将深入探讨这套解决方案，了解以下几项核心要点：
- 为分类器构造训练数据
- 分类器的CNN架构
- 模型评估
- 在线检测模型
为分类器构造训练数据
为了构建分类器，Infoblox 编写了一部分代码，以类似于 MNIST 的格式构造训练数据。MNIST（美国国家标准技术研究院）发布了一套大型手写数字图像数据库，目前这套数据库已经成为深度学习/计算机视觉从业者群体中“Hello World”般的存在。其中每张图像尺寸为28 x 28像素，Infoblox 的代码使用以下素材为每个字符创建对应变体：
- 视觉上容易混淆的各字符的 Unicode 标准列表（最新版本为13.0.0）及其安全考量因素，用于帮助开发人员避免视觉欺诈攻击并采取适当的应对举措。
- 包含变音标记块中各常见组合字符的 Unicode 标准块。例如，在以下来自维基百科组合变音符词条的图表当中，我们可以看到U+300块与U+300x行交汇于列0处；U+300似乎代表重音，因为我们能够在法语中看到“è”字符。其中部分组合变音符号不太显眼（例如U+0363），因此适合被整理起来用于构建训练数据集。关于更多详细信息，请参阅 Unicode 网站上的组合变音符部分。
- 多种字体。攻击者可以通过恶意渲染从根本上改变字符的开关。例如，Infoblox 就使用到本地系统中的多种字体，同时也可以添加第三方字体（例如Google Fonts）等本应被排除的脚本字体。在此用例中，使用不同字体为各个字符生成多种变体，属于一种强大的图像增强技术。在这一阶段中，Infoblox 选择了65种字体以生成训练数据集。这一字体数量足以建构建起一致性训练集，由此带来不错的预测准确率。使用更少的字体将无法为各个字符创建充足的表示形式，而字体超过65种之后则很难进一步提升模型的准确率。
未来，Infoblox 还计划使用其他数据增强技术（例如翻译、缩放与剪切等操作）进一步提高 ML模型的健壮性。实际上，每款深度学习框架的SDK都提供有丰富的数据增强功能，用户可以根据需求将其湢至数据准备管道当中。
分类器的CNN架构
在训练数据集准备就绪之后，Amazon SageMaker 立即跟上，提供一套几乎无需任何学习曲线即可快速上手的模型训练流程。以此为基础，Infoblox 采用以下 CNN 架构构建分类器方案。
这套 CNN 神经网络围绕两个连续的 CONV-POOL 单元构建而成。卷积部分将自动从输入的图像中提取特征，分类部分则使用这些特征将输入图像映射（分类）至 ASCII 字符。最后一层负责将分类网络的输出结果，转换为输入中各个类（例如ASCII字符）的概率向量。
Infoblox 已经着手构建新的 TensorFlow 模型，这套模型能够直接导入 Amazon SageMkaer 之内。以此为基础，他们使用多项 Amazon SageMaker 功能以加速并推进模型的开发工作：
- 支持使用CPU及GPU实例进行分布式训练 – Infoblox 主要使用 ml.c4.xlarge（计算）与ml.p2.xlarge（GPU）实例。尽管每轮训练周期并不太长（大约20分钟），但考虑到可观的参数数量及其细粒度搜索空间，每项超参数调整工作仍然有可能耗费7个小时以上。更重要的是，Infoblox需要在后台的众多实例之上分配工作负载，同时摆脱一切由基础设施管理带来的额外负担。
- 直接在notebook环境中训练、部署并测试模型的预测能力 – 就在用于数据整理与准备的同一套环境当中，Infoblox 使用Amazon SageMaker以透明方式启动并管理训练集群与推理端点。这些基础设施独立于 Amazon SageMaker notebook 实例之外，并由SageMaker服务全权管理。
借助丰富的现有文档与大量示例notebook，Infoblox 得以轻松使用 AWS 发布在GitHub repo上以及 Amazon SageMaker notebook 环境中的现成素材，极大降低了机器学习技术的实现难度。
在初始阶段，Infoblox 使用几行代码在 Amazon SageMaker 中对 TensorFlow 训练脚本进行本地测试。以本地模式进行训练具有以下几项优势：
- Infoblox 可以轻松监控各项指标（例如GPU资源消耗量），并保证编写的代码能够在训练过程中充分发挥硬件性能优势。
- 在调试过程中，应考虑对训练脚本及推理脚本进行即时更改，提升代码迭代的易行性。
- 无需等待Amazon SageMaker 置备训练集群，脚本可以立即开始运行。
在Amazon SageMaker 当中以本地模式工作将带来巨大的灵活性优势，这也是将现有工作负载迁移至云端的关键所在。您还可以在本地实例上部署 Amazon SageMaker TensorFlow 服务容器，在本地对推理代码进行原型设计。如果大家对模型及训练效果感到满意，只需更改几行代码，即可切换至分布式训练与推理模式，由此创建出新的估计器、优化模型甚至将训练好的模型部署至持久端点当中。
使用本地模式完成数据准备与训练过程之后，Infoblox开始在云端进行模型调优。这部分工作先从一组粗略的参数开始，并通过多个调整工作逐步实现参数完善。在此期间，Infoblox 使用 Amazon SageMaker 超参数调优帮助他们选择最佳超参数值。以下几项超参数值，似乎对模型性能具有最大影响：
- 学习率
- 丢弃(Dropout)率（正则化）
- 卷积层的内核各维度
在优化模型并达到所需的准确率与F1性能得分之后，Infoblox 团队将模型正式部署至 Amazon SageMaker 端点。为了增强安全性，Amazon SageMaker 端点被部署在隔离的专用实例当中，因此需要另行置备并等待几分钟后方可执行新的预测。
要获得良好的准确率，我们自然需要对训练、验证及测试数据集进行甄选或清洗。例如，为了选择并覆盖训练集中的65种字体，Infoblox 团队需要输出其工作站上的全部可用字体，并手动检查以选择相关度最高的字体。
模型评估
Infoblox 使用准确率与F1得分作为评估 CNN 分类器性能的主要指标。
准确率，代表的是模型在正确识别同形异义词方面的得分。其基本定义，是在模型生成的预测总数中，找到预测正确的数量与比例。Infoblox 得出的准确率高于96.9%（换言之，在该模型做出的1000项预测中，至少有969项实现了对同形异义词的正确分类）。
此外，分类问题中的精度与召回率也是两项重要的评估指标。
精度，是指正确识别与正确识别加错误识别加和之间的比值：
召回率，则是指正确识别与正确识别加错误忽略加和之间的比值：
Infoblox使用F1得分作为组合指标，其中对精度及召回率进行了谐波平均值计算。如此一来，模型将在这两项指标之间取得良好的平衡。
从业务影响的角度来看，降低错误忽略的重要性往往高于错误识别。错误忽略也可称为漏检，即模型未能正确识别出属于异常状况的因素，大家可以使用分类器缓解这类问题。在另一方面，错误识别也会给最终用户带来负面影响，例如根据检测器中的错误结果在DNS解析配置内意外阻止了本应正常执行的响应策略。
在线检测模型
下图所示，为在线检测模型的基本架构。
这套在线模型使用以下 AWS 组件：
- Amazon Simple Storage Service (Amazon S3)，用于存储训练与测试数据集（1）、Unicode字形（1）、Passive DNS数据集、历史数据以及模型（3）。
- Amazon SageMaker，用于训练CNN模型（2），并使用同形异义词分类器（4）进行离线推理。输出结果为 ASCII 到 Unicode的映射（5）。
- AWS Data Pipeline，运行批量检测管道（6）并管理Amazon EMR集群（创建集群，分步提交不同的处理请求，直到集群关闭）。
- Amazon EMR，负责为批处理与流式管道运行ETL作业。
- 批处理管道从Amazon S3中读取输入数据（加载目标列表并读取 Passive DNS 数据（7））、应用ETL操作（8），并将结果提供给在线检测系统（10）。
- 示例中使用的在线检测系统为流式管道，虽然与批处理管道采用相同的转换方式（10），但会通过订阅 Apache Kafka 代理（11）以获取额外数据。
- Amazon DynamoDB (一款NoSQL数据库)，用于保存来自检测算法（在线系统）的详细检测数据（12）。其以高强度写入访问为主（大型数据集，读取频率较低）。
- Amazon RDS for PostgreSQL，用于存储检测结果的子集，同时随附关于结果的简短说明（13）。Infoblox 在实际应用中发现，Amazon RDS 非常适合存储一部分需要在用例中进行高频读取访问的结果，能够在提升性能表现的同时有效控制成本。
- AWS Lambda函数，用于编排及连接架构中的不同组件。
这套整体架构还符合其他 AWS 服务的相关最佳实践，包括Amazon Virtual Private Cloud (Amazon VPC), Elastic Load Balancing以及 Amazon Elastic Block Store (Amazon EBS)。
总结
Infoblox 团队使用 Amazon SageMaker 训练出一套深度CNN模型。此模型能够识别出与DNS域名中 ASCII 字符在外观上高度相似的Unicode字符。以此为基础，该模型还使用Unicode标准识别这些同形异义字符，验证准确率为0.969，测试F1得分为0.969。接下来，他们又编写一款检测器，使用此模型对 Passive DNS 流量上的 IDN 同形异义词进行检测，整个流程无需进行任何在线图像数字化或预测操作。截至本文撰稿时，这款检测器已经识别出超过6000万条同形异义词域名，其中相当一部分与知名在线品牌相关。在检测涵盖的6万种不同品牌中，模型发现了50多万种独特的同形异义词，并确定针对100个行业的实际攻击活动，其中大多数（约49%）指向金融服务领域。
结合实际情况可以看到，IDN 在不经意间给攻击者留下了巨大的可利用空间，且同形异义字的使用范围远超品牌所有方的基本预期。各类组织机构应考虑针对同形异义词进行 DNS 活动监控，单纯依靠预先注册同形异义词域名显然无法达成良好的品牌保护效果。
以下截图展示了同形异义字域名里，网页内容与他们试图模拟的域名对比。左侧为同形异义域的内容，在右侧显示真实域名的内容。
Amazon: xn--amzon-hra.de => amäzon.de vs. amazon.de。请注意同形异义词域名页面上的空白区域。
Google: xn--goog-8va3s.com => googļę.com vs. google.com。同形异义域名的页面上存在一个顶部菜单栏。
Facebook: xn--faebook-35a.com => faċebook.com vs. facebook.com。除非一一对比查看，否则很难发现二者之间的区别。
