黑客技术网

AI 时代网络钓鱼攻击的新挑战与应对策略

Tue, 14 Jan 2025 21:52:52 +0800

在网络安全领域，攻防竞赛持续上演。随着防御策略的迭代升级，攻击者也在不断探寻强化攻击效果的新技术。当下，在网络钓鱼活动中，AI 技术的应用与传播速度令人咋舌，甚至在不久的将来，传统人工网络钓鱼攻击或被其彻底取代。这一趋势下，企业组织面临着严峻的安全挑战。

AI 网络钓鱼攻击的新挑战

网络钓鱼攻击，简而言之，是攻击者借助虚假身份与欺骗手段，通过网站、语音、短信、邮件、Wi-Fi 等渠道，诱导用户泄露用户名、密码、银行账户等个人敏感信息的网络攻击形式。随着人工智能技术的普及与精进，威胁行为者利用其对传统网络钓鱼攻击进行改造，带来了一系列安全挑战。

社会工程利用升级：AI 技术能让攻击者更娴熟地运用社会工程技巧，显著提升网络钓鱼活动的成效。借助 AI，攻击者可获取海量数据，为每个攻击目标定制个性化的网络钓鱼电子邮件。这种个性化操作极大地增加了检测攻击意图的难度。

欺诈内容高度逼真：运用 AI 技术生成的钓鱼内容，在语法、风格和语气上与合法通信极为相似，使得欺诈信息极难被察觉。

攻击可扩展性增强：AI 技术助力网络钓鱼活动实现不同攻击阶段的自动化，如电子邮件的创建、分发以及响应处理。攻击的自动化使得更多企业和用户沦为攻击目标。

自适应规避检测：AI 能协助攻击者依据攻击反馈进行效果优化，致使现有的安全防护系统难以跟上网络钓鱼策略的演进速度。在 AI 的支持下，网络钓鱼者能采用多种规避手段，绕过反网络钓鱼措施或电子邮件过滤器。AI 的自适应能力促使攻击者持续改进攻击策略，让检测和缓解此类网络钓鱼攻击愈发困难。

目标定位精准化：AI 技术能够广泛收集和深入分析目标企业的大量公开信息，进而据此量身定制网络钓鱼剧本。由于这些信息对受害者而言既相关又真实，极大地提高了攻击的成功率。

深度伪造技术滥用：网络钓鱼攻击不仅局限于书面文字，常见的 “语音钓鱼”（vishing）涉及语音通话。AI 使得攻击者能够模仿特定人的声音并制作令人信服的虚假录音。

积极应对 AI 时代的新型网络钓鱼

尽管网络钓鱼攻击者已将 AI 用于恶意目的，但企业用户和网络安全厂商必须勇于迎接挑战，争取在新型网络钓鱼攻击面前占据主动。可采取以下积极措施来应对 AI 增强的网络钓鱼攻击。

部署 AI/ML 支持的高级威胁检测系统：用于发动复杂网络钓鱼攻击的 AI 技术，同样是战胜它们的有力武器。企业应将 AI 和 ML 技术融入现有的网络安全系统，提升对新型威胁的预测分析能力。在 AI 技术的助力下，这些系统能够从每次攻防对抗中学习，随着时间的推移变得更加智能和高效。通过分析异常用户行为模式和习惯，新一代高级威胁检测系统能够识别潜在的钓鱼攻击。

设计便捷的网络钓鱼报告机制：为有效应对 AI 增强的新型网络钓鱼攻击，企业需及时向安全人员通报正在发生的网络钓鱼活动。便捷的报告机制既能快速通知每一位员工，又能为反网络钓鱼工具和人工智能检测模型提供关键信息。在构建该机制时，不仅要确保提交报告简便易行，还需保证其能够收集尽可能多的钓鱼活动信息，以提升其价值和可操作性。网络钓鱼报告机制应成为企业构建强大安全防护基础设施的重要环节，尤其是在 AI 钓鱼活动日益猖獗的背景下，有效的报告至关重要，因为攻击者也会通过自动化手段收集和整合各类信息，从而扩展网络钓鱼攻击的能力。

采用更有效的身份验证措施：基于密码的身份验证方式极易受到新型网络钓鱼的攻击。然而，目前已有多种能够有效抵御网络钓鱼的身份验证新方法。Passkey 技术作为其中之一，正逐渐成为主流。此外，采用多因素身份验证（MFA）方式能为企业应对新型网络钓鱼活动增添一层安全保障。即便网络钓鱼攻击成功迷惑了员工，企业仍可借助 MFA 阻止攻击者访问敏感数据。MFA 要求多种形式的身份验证，攻击者仅凭被盗凭据无法获取关键数据的访问权限。

部署电子邮件安全网关：当下，主流的电子邮件安全网关系统在应对电子邮件钓鱼攻击时功能强大。它们在审查收到的电子邮件时，运用先进的 AI 算法全面分析电子邮件的各项安全指标，包括发件人的安全声誉、链接和附件等。通过部署电子邮件安全网关，企业能够在钓鱼邮件被用户打开之前，有效识别并过滤掉这些邮件。

重视员工安全意识培养：借助技术手段抵御网络钓鱼活动固然重要，但在对抗 AI 网络钓鱼的过程中，人始终是第一道防线，也是最为关键的因素。反网络钓鱼的核心在于提高全体员工的网络安全素养。因此，企业应高度重视培养员工和合作伙伴识别网络钓鱼的能力，确保开展广泛的网络安全意识培训，同时保证掌握较大权限的用户能够抵御较为高级的钓鱼攻击。

USB 设备模拟与 Linux 内核驱动调试技术探索

Tue, 14 Jan 2025 21:37:51 +0800

深入探索，尝试对 USB 和游戏手柄进行模拟。这不仅能加深我们对 USB 设备工作原理的理解，还能为开发各类有趣的应用提供技术支持。

一、USB 模拟

修改协议：在脚本中，将表示设备类型的协议值修改为 2，以表示设备。具体操作为：echo 2 > "${FUNCTIONS_DIR}/protocol" # mouse。

修改 HID 描述符：HID 描述符需要定义按键、坐标和滚轮等功能。现代功能丰富，除了基本的左右键，还有中键、滚轮以及一些额外按键。我们编写的 HID 描述符如下：

这段描述符中，首先定义了 5 个按键，每个按键占 1bit，用于表示左键、右键、中键和两个侧边按键。按键状态通过 0 和 1 表示，按下为 1，释放为 0。接着定义了 XY 直角坐标系，用于表示鼠标的移动，每个轴的取值范围是 - 0x7FFF 到 0x7FFF，占 16bit。最后定义了滚轮，取值范围是 - 0x7F 到 0x7F，占 8bit。通过这些定义，我们能够全面地模拟鼠标的各种功能。

完成上述修改后，运行 bash 脚本，通过写 /dev/hidg0 文件，就能实现对主机上鼠标的控制，包括点击和移动。例如，点击左键的代码如下：

需要注意的是，这样的操作只实现了按下左键，并没有释放。要实现完整的点击过程，需要分别发送按下和释放的指令，代码如下：

对于鼠标的其他功能，如控制其他按键、横向和纵向移动以及滚轮滚动，只需对 mouse_buf 数组中的相应位进行修改即可。

二、USB 游戏手柄模拟

（一）普通游戏手柄模拟

在成功模拟 USB 鼠标和键盘后，模拟一个普通的 USB 游戏手柄也变得可行。首先，我们需要修改模拟脚本中的一些参数，以确保设备被正确识别为游戏手柄：

当 protocol 设置为 0 时，设备不会被鼠标和键盘的驱动识别，而是会被游戏手柄的驱动根据 idVendor 和 idProduct 进行匹配。在 Linux 系统中，游戏手柄的驱动代码通常位于 drivers/input/joystick/xpad.c，我们可以查看该驱动中能识别的 XBox 游戏手柄列表，确认我们模拟的手柄型号（这里是 Microsoft X-Box 360 pad）是否在其中。

接下来，我们需要编写游戏手柄的 HID 描述符，以定义其功能和按键布局：

这个 HID 描述符定义了 14 个按键，用于实现各种游戏操作。同时，还定义了一个 Hat Switch，用于控制方向，其值用 4bit 表示，代表上下左右四个方向，移动距离以厘米为单位，最大值为 315cm。此外，还定义了四个摇杆控制轴（XYZRz），每个轴的值占 8bit，用于精确控制游戏中的角色移动和视角。

完成上述设置后，运行脚本，我们可以在 Linux 主机上看到相关的设备信息。通过查看 /dev/input 目录，我们可以发现新增了与游戏手柄相关的文件，如 js1 和 event6。我们可以通过读取这些文件来获取手柄的输入信息，例如使用以下命令查看 js1 文件的内容：cat /dev/input/js1|hexdump -C。为了更直观地观察手柄的输入，我们还可以编写一个 Python 脚本来解析 js1 文件的数据结构：

这个脚本能够实时输出手柄的操作信息，包括操作时间、操作值、操作类型和操作的按键或轴编号。通过分析这些信息，我们可以更好地理解手柄的工作原理和用户的操作行为。

（二）深入研究游戏手柄

在最初研究游戏手柄时，我们考虑通过抓包分析现成手柄的数据来进行模拟。我们选择了 Switch Pro 手柄和一款国产手柄作为研究对象，并在 Linux 源码中发现了与 Switch 手柄相关的驱动：drivers/hid/hid - nintendo.c。然而，在实际研究过程中，我们遇到了一些问题。

正版的 Switch Pro 手柄在接入 Windows 或 Ubuntu 系统时，虽然能够抓到 USB 数据包和 HID 描述符，但主机无法正常使用手柄。在 Windows 系统上，由于缺乏逆向驱动的经验，我们暂时无法深入研究。而在 Ubuntu 系统上，通过查看日志发现，虽然系统成功适配到了 hid_nintendo 驱动，但出现了大量错误，导致手柄驱动注册失败，无法在 /dev/input 目录下生成相应的文件。这些错误主要与读取 SPI flash 失败以及校准数据读取失败有关。

对于国产手柄，其在 Windows 系统上会伪装成 Switch Pro 手柄，当检测到无法正常使用时，会再次伪装成 XBox 手柄。然而，该手柄在代码实现上可能存在严重问题，导致在使用 USBTree View、Wireshark 的 USBPcap 以及 Windows 部分 USB 驱动时出现崩溃现象，甚至影响到 Linux 虚拟机中的 USB 驱动识别。这可能是由于手柄存在防破解机制，导致在进行抓包和分析时出现异常。

由于以上问题，我们决定对 Linux 内核中的 nintendo 驱动进行研究和调试。调试驱动的方法有多种，包括使用 eBPF、开启内核编译的 DEBUG 参数以及编辑驱动源码添加调试输出。经过分析，我们选择了编辑驱动源码的方法，因为这种方法相对耗时较少。

三、动态修改 Ubuntu 驱动

（一）安装内核源码

为了修改驱动，我们首先需要安装与当前内核版本相同的内核源码。通过以下命令可以获取当前内核版本，并安装相应的内核源码：

（二）编写驱动编译加载脚本

为了方便地重新编译和加载驱动，我们编写了一个脚本，该脚本能够在修改驱动后快速完成编译和加载操作：

这个脚本接受一个参数，即驱动名称。它首先卸载当前的驱动模块，然后使用 make 命令重新编译驱动，并使用脚本对编译后的驱动进行签名，最后将新的驱动模块加载到内核中，并实时查看内核日志以观察驱动的加载情况。

（三）添加调试输出

为了更好地调试 nintendo 驱动，我们可以通过两种方式添加调试输出：

定义新的调试函数：参考 hid_dbg，我们定义了一个新的调试函数 mhid_dbg，用于输出调试信息。通过将 hid - nintendo.c 中的 hid_dbg 替换为 mhid_dbg，我们可以在驱动运行时输出更多详细的信息。

使用 print_hex_dump 函数：在 nintendo_hid_event

Java 开发中的字节码操控利器：JavaAssist

Sun, 12 Jan 2025 22:33:38 +0800

在 Java 开发的广袤领域中，字节码操作作为一项高级技术，犹如一把神奇的钥匙，能够在运行时对类的行为进行修改或生成。而 JavaAssist，作为一款开源的字节码操作库，以其独特的魅力，为开发者提供了一种相对简易的途径来驾驭 Java 字节码，使得开发者能够以近乎 Java 代码的直观形式，在字节码层面大展身手。接下来，我们将全方位深入探索 JavaAssist 的功能、使用技巧以及实际应用场景。

JavaAssist：字节码操作的得力助手

JavaAssist 堪称一种卓越的高级字节码操纵工具，它另辟蹊径，提供了一种更为简洁的方式来对 Java 字节码进行编辑与创建。相较于直接使用诸如 ASM 这类底层的 Java 字节码操作库，JavaAssist 凭借其精心设计的高级 API，极大地拉近了字节码操作与 Java 编程本身的距离。下面，让我们一同深入剖析 JavaAssist 的技术原理，涵盖其工作机制、核心组件以及实现方式等关键方面。

工作机制：灵活操控类文件的魔法

JavaAssist 的舞台搭建在 Java 的类文件（.class 文件）层面，它宛如一位技艺精湛的舞者，能够在类被加载到 JVM 之前，亦或是类加载的瞬间，灵动地对类的结构与行为进行动态修改。JavaAssist 主要通过以下两种巧妙的方式来施展其魔法：

1. 类文件的直接编辑：JavaAssist 具备读取现有.class 文件的能力，如同一位敏锐的读者，能够精准地解析文件内容。不仅如此，它还能够像一位富有创造力的工匠般生成全新的类文件。在这之后，借助自身丰富的 API，JavaAssist 可以对类的结构进行细致入微的雕琢，例如添加全新的字段与方法，或者对已有的字段和方法进行修改等操作。

2. 类加载时的动态修改：JavaAssist 巧妙地通过定义类加载器，或者借助 Java 的 Instrumentation API，成功获得了在类被加载到 JVM 这一关键时刻修改其字节码的超能力。这就好比在类进入 JVM 的大门时，JavaAssist 能够恰到好处地为其 “梳妆打扮”，赋予类全新的特性。

核心组件：构成 JavaAssist 大厦的基石

JavaAssist 的精彩表现离不开以下几个核心组件，它们犹如大厦的基石，共同支撑起了 JavaAssist 强大的功能：

1. ClassPool：在 JavaAssist 的体系中，ClassPool 无疑是最为关键的一个类，它就像一个庞大且有序的仓库，充当着类数据的容器。ClassPool 兢兢业业地管理着 CtClass 对象，每一个 CtClass 对象都如同一个独特的标签，代表着一个具体的 Java 类。ClassPool 提供了一系列丰富且实用的方法，让开发者能够轻松地读取和编辑这些类，仿佛拥有了一把开启类数据宝库的万能钥匙。

2. CtClass：CtClass，即 “compile - time class” 的缩写，形象地代表着一个 Java 类。它就像一个功能齐全的工作室，为开发者提供了编辑类的各种接口。在这里，开发者可以像一位技艺娴熟的设计师，自由地添加字段、方法、构造函数等，对类进行全方位的设计与塑造。不过需要注意的是，CtClass 对象一旦被 “冻结”（即调用了 toClass () 方法后），就如同一件完成的艺术品，不能再进行修改了。

3. CtMethod 和 CtField：这两个类分别扮演着类中方法和字段的 “代言人” 角色。它们赋予开发者获取和设置方法代码，以及字段属性的能力。通过 CtMethod 和 CtField，开发者可以深入到类的内部，对方法和字段进行精准的操作，就像在精密的仪器上进行微调一样。

4. CtNewMethod 和 CtNewConstructor：这两个工具类堪称 JavaAssist 的得力助手，它们专门用于快速创建新的方法和构造函数。当开发者需要为类添加新的行为或者初始化逻辑时，CtNewMethod 和 CtNewConstructor 就能大显身手，帮助开发者高效地完成任务，如同为开发者配备了一套便捷的工具套装。

实现方式：步步为营的字节码修改之旅

JavaAssist 对类的修改是通过有条不紊地操纵字节码来实现的，其基本流程宛如一场精心编排的舞蹈，每个步骤都紧密相连：

1. 读取或创建类：首先，开发者需要借助 ClassPool 这个 “魔法容器”，通过其提供的方法获取已有的类，或者创建一个全新的 CtClass 对象。这就好比在一个巨大的素材库中挑选所需的素材，或者从零开始创作一个新的素材。

2. 修改类结构：在获取或创建好 CtClass 对象后，开发者就可以大展拳脚了。通过添加、修改或删除 CtField 和 CtMethod 等组件，如同在搭建一座积木城堡一样，逐步改变类的结构，使其符合自己的需求。

3. 应用修改：当类的结构修改完成后，就到了将这些修改应用到实际中的时刻。开发者可以调用 CtClass 的toClass()方法，将修改后的类优雅地加载到 JVM 中，使其在运行时发挥新的作用；或者调用writeFile()方法，将其写入文件，保存这一精心打造的成果，以备后续使用。

示例：动态代理实现的精彩演绎

假设我们面临这样一个实际需求：为一个接口创建一个动态代理，并且在每个方法调用的前后都添加日志输出，以便更好地追踪和监控接口方法的执行情况。此时，JavaAssist 就能大显身手，帮助我们轻松实现这一目标。以下是具体的实现代码：

在这个示例中，我们清晰地看到了如何运用 JavaAssist 动态创建实现了指定接口的类，并在每个方法中巧妙地添加了简单而实用的日志输出语句。这种技术在实际开发中具有广泛的应用前景，例如可以应用于 AOP（面向切面编程）框架，实现诸如日志记录、事务管理等横切关注点的功能；也可以在模拟测试对象时发挥重要作用，帮助开发者更方便地验证和测试代码的功能。它就像一把万能钥匙，为我们打开了 Java 开发中许多复杂场景的解决方案之门。

SQL 注入：威胁与防范

Sun, 12 Jan 2025 22:21:07 +0800

在当今数字化时代，网络安全至关重要。其中，SQL 注入（SQL Injection）作为一种常见且极具威胁性的网络攻击手段，通过在应用程序输入数据中巧妙插入恶意 SQL 代码，达到操纵数据库执行未经授权操作的目的。这一攻击方式常利用应用程序对用户输入验证不足的漏洞，攻击者借此可获取敏感信息、篡改数据，甚至完全掌控数据库系统。过去二十年，随着互联网的迅猛发展，SQL 注入一直是数据泄露的主要元凶之一，因此，深入了解并有效预防 SQL 注入，对保护信息安全意义重大。

整体架构流程

在探讨 SQL 注入之前，有必要先明晰典型 Web 应用程序与数据库的交互机制。Web 应用程序通常采用前端、后端和数据库的三层架构。用户在前端输入信息，后端负责将这些信息传递给数据库，执行相应的 SQL 查询或命令。数据库处理完毕后，将结果返回后端，再由后端展示给用户。

SQL 注入攻击流程

1. 输入点识别：攻击者的首要任务是找出应用程序中可能存在 SQL 注入漏洞的输入点。这些输入点常见于用户可输入数据之处，如登录表单、搜索框、URL 参数等.

2. 恶意 SQL 语句构造：攻击者在识别出的输入点注入精心构造的恶意 SQL 代码。由于应用程序未对输入数据进行充分验证或过滤，这些注入的 SQL 代码会直接拼接到 SQL 查询中。

3. 恶意 SQL 代码执行：数据库接收到攻击者构造的恶意 SQL 查询后便会执行。依据查询内容，攻击者能够获取数据库中的敏感数据、修改表结构，甚至删除数据。

4. 数据获取或破坏：执行后的 SQL 查询结果通常会反馈给攻击者，使其成功获取敏感信息或对数据库造成破坏。

防御流程

1. 输入验证与过滤：在后端代码中对用户输入进行严格验证和过滤，确保仅接受合法的数据格式。

2. 使用预编译语句：通过运用预编译语句（Prepared Statements）和参数化查询，避免 SQL 语句与用户输入直接拼接，从根源上杜绝 SQL 注入。

3. 遵循最小权限原则：限制数据库用户权限，确保即便攻击者成功注入 SQL 语句，也难以对数据库造成严重破坏。

4. 定期安全测试与监控：定期开展安全测试（如渗透测试）并监控数据库访问日志，及时发现并修复潜在安全漏洞。

例如

在语言模型中，编码器和解码器均由多个 Transformer 组件拼接而成。

技术名词解释

1. SQL（Structured Query Language）：一种用于访问和管理关系数据库的标准化编程语言，涵盖数据查询、更新、删除、插入等操作。

2. SQL 注入：攻击者通过在用户输入字符串中插入恶意 SQL 代码，以执行未经授权数据库操作的攻击技术。

3. 参数化查询（Parameterized Query）：一种防止 SQL 注入的方法，SQL 语句在执行前预编译，用户输入作为参数传递，避免与 SQL 语句直接拼接。

4. Prepared Statements：预编译的 SQL 语句，支持参数化查询，有助于防范 SQL 注入攻击。

5. Web 应用防火墙（WAF）：专门用于过滤、监控和阻止 HTTP 流量中恶意请求的防护措施，常用于防御 SQL 注入等常见 Web 攻击。

6. 渗透测试（Penetration Testing）：模拟攻击者对系统进行测试，以发现并及时修复系统中的安全漏洞。

技术细节

输入验证与过滤

开发者在处理用户输入时，应始终假定用户输入不可信。对于文本框、URL 参数、Cookie 等任何可能接收用户输入的位置，都必须进行严格验证和过滤。可采用白名单验证方式，确保输入仅包含允许的字符和格式。同时，避免在 SQL 查询中直接使用用户输入数据，防止恶意代码注入。

常见的输入验证与过滤方法如下：

1. 正则表达式过滤：借助正则表达式限制输入格式。

2. 字符转义：对输入中的特殊字符进行转义处理，使其无法作为 SQL 代码的一部分执行。

3. 限制输入长度：防止过长数据输入引发缓冲区溢出等问题

使用预编译语句和参数化查询

预编译语句和参数化查询是防范 SQL 注入的有效手段。通过将 SQL 查询与用户输入分开处理，数据库仅执行预编译的 SQL 语句，用户输入仅作为参数传递，无法影响 SQL 语句结构。

最小权限原则

数据库用户应遵循最小权限原则，仅赋予其完成任务所需的最低权限。即便攻击者获取该用户凭据，也难以对数据库造成重大破坏。常见的权限设置如下：

1. 只读权限：对于无需修改数据的操作，限制为只读权限。

2. 限制访问范围：限定用户只能访问某些特定的表或数据库。

3. 监控与审计：开启数据库审计功能，记录所有查询和操作，便于事后分析和追踪。

定期安全测试与监控

安全测试是保障系统安全的关键环节。通过渗透测试，可模拟攻击者行为，发现系统漏洞。

小结

SQL 注入虽是一种古老的攻击手段，但至今仍极具效力，对应用程序安全性构成严重威胁。通过严格的输入验证与过滤、使用预编译语句和参数化查询、遵循最小权限原则以及定期进行安全测试和监控，我们能显著降低 SQL 注入攻击风险。然而，随着攻击手段不断演变，我们必须保持警惕，及时更新防护措施，确保系统安全。

本文为网络安全技术研究记录，文中技术研究环境为本地搭建或经过目标主体授权测试研究，内容已去除关键敏感信息和代码，以防止被恶意利用。文章内提及的漏洞均已修复，在挖掘、提交相关漏洞的过程中，应严格遵守相关法律法规。

DNS 技术全解析：从原理到安全防护与威胁应对

Sat, 11 Jan 2025 21:05:46 +0800

一、DNS 解析过程深度剖析

（一）递归解析：一站式的解析服务

递归解析是 DNS 解析过程中一种常见且高效的方式。当用户在浏览器等应用程序中输入网址时，DNS 客户端便会向本地 DNS 解析器发起解析请求。这就好比用户向一位知识渊博的 “本地专家” 请教某个信息，而这位 “专家” 会全权负责查询最终结果，并将其反馈给用户。

在这个过程中，本地 DNS 解析器会代替客户端完成中间所有的查询请求。它就像一个不知疲倦的 “跑腿员”，从根 DNS 服务器开始，沿着顶级域名服务器、权威域名服务器等层层查询，直至获取到目标域名对应的 IP 地址，然后将这个结果返回给客户端。整个流程就像一场精心策划的接力赛，本地 DNS 解析器承担了全部的 “奔跑” 任务，确保客户端能够快速、准确地获得所需信息。

（二）迭代解析：逐步探索的解析之旅

迭代解析与递归解析有所不同，它是由 DNS 客户端亲自 “出马”，逐步向各级 DNS 服务器发起请求。每一次请求，客户端都会从当前级别的 DNS 服务器获得下一级服务器的地址，然后继续向下一级服务器发送查询请求，如此反复，直到最终获取到目标域名的 IP 地址。

这就好比用户在一个陌生的城市寻找目的地，每到一个路口，就向路人询问下一个路口的方向，逐步找到最终的目的地。在这个过程中，客户端需要自主完成每一级的查询，而不像递归解析那样依赖本地 DNS 解析器进行递归查询。

在实际的 DNS 架构中，本地 DNS 服务器常常采用迭代解析的方式。有趣的是，如果终端设备本身具备强大的解析能力并采用迭代解析，那么理论上就可以不再依赖本地 DNS 服务器，直接与各级 DNS 服务器进行交互。

二、DNS 安全技术全景展示

（一）DNSSEC：为 DNS 加上数字锁

DNSSEC，即域名系统安全扩展，是一组旨在为 DNS 提供源身份验证和数据完整性保障的重要协议。在当今复杂多变的网络环境中，数据在传输过程中面临着被篡改或伪造的风险，而 DNSSEC 就像一把坚固的 “数字锁”，通过使用数字签名技术，为 DNS 数据的传输保驾护航。

当 DNS 数据在网络中传输时，DNSSEC 会对其进行签名验证，确保数据的来源真实可靠，并且在传输过程中没有被篡改。这就如同给每一份重要文件都盖上了独一无二的印章，只有印章正确，文件才能被认为是真实有效的。DNSSEC 的主要目的就是通过这种方式，增强 DNS 的安全性，让用户能够放心地使用 DNS 服务。

（二）DoH：让 DNS 查询走加密通道

DNS over HTTPS（DoH）是一种创新性的技术，它将 DNS 查询巧妙地通过 HTTPS 协议进行发送。HTTPS 协议以其强大的加密和认证特性而闻名，DoH 正是借助了这一特性，为 DNS 查询和响应穿上了一层坚固的 “防护衣”。

在传统的 DNS 查询过程中，数据以明文形式传输，这使得攻击者有机会窃取或篡改查询信息。而 DoH 的出现改变了这一局面，它将 DNS 查询封装在 HTTPS 协议中，使得查询过程变得更加安全和私密。这就好比将重要的信件放在了一个加密的信封中进行传递，只有收件人能够正确打开并读取其中的内容。

（三）DoT：另一种加密选择

与 DoH 类似，DoT（DNS over TLS）同样致力于提升 DNS 的安全性。它的独特之处在于，将 DNS 的 Payload 直接放置在 TLS 协议的上层。TLS 协议也是一种广泛应用的加密协议，DoT 通过这种方式为 DNS 通信提供了加密保护。

DoT 和 DoH 虽然在实现方式上略有不同，但它们的目标是一致的，都是为了确保 DNS 查询和响应在传输过程中的安全性，防止信息被窃取或篡改。就如同两条不同的加密道路，都通向 DNS 安全的目的地。

（四）HttpDNS：非标准但实用的解析方案

HttpDNS 严格来说并不能算作传统意义上的 DNS，它提供了一种非标准的域名解析方式。初看之下，它与 DoH 有不少相似之处，但实际上，两者的设计目的大相径庭。

DoH 作为一个通用服务，其核心目标是增强 DNS 本身的安全性，使其在整个网络环境中更加可靠。而 HttpDNS 则是一个针对特定业务需求的非标准服务，通常只专注于解析业务需要用到的几个域名。它在手机 App、桌面客户端、嵌入式设备等场景中应用广泛。

例如，在一些手机应用中，为了确保关键域名的解析准确性和稳定性，开发者会选择使用 HttpDNS。它就像一个定制化的导航仪，只为特定的 “路线” 提供精准的导航服务。

三、常见 DNS 威胁与应对策略

（一）DNS 缓存污染：虚假信息的潜伏危机

DNS 缓存广泛分布在全球各地开放的 DNS 服务器中，它的设计初衷本是为了加速 DNS 查询的响应时间，并减少 DNS 查询请求对 DNS 服务器造成的压力。当用户发起对某个域名的解析请求时，DNS 服务器会首先在自身的 DNS 缓存中查找是否有对应的结果。如果能够命中缓存，服务器就会直接将结果告知客户端，无需再进行耗时的全球解析查询。

然而，DNS 协议在设计时存在一个漏洞，即缺乏相关的记录完整性认证机制。这就给了攻击者可乘之机，他们有可能篡改上游 DNS 服务器的结果，使得最终错误的结果被缓存起来。当其他用户再次查询相同域名时，就会收到这个错误的解析结果，从而被引导到错误的网站，面临信息泄露、遭受恶意攻击等风险。

针对这一威胁，DNSSEC 是一种有效的缓解及防御措施。通过使用 DNSSEC，DNS 数据在传输过程中会经过数字签名验证，确保缓存的结果真实可靠，从而防止 DNS 缓存被污染。然而，在实际应用中，DNSSEC 的性价比并不高。一方面，现阶段 HTTPS 已经成为主流，即便 DNS 解析结果出现错误，在 HTTPS 握手阶段也能够被检测出来。另一方面，虽然大部分 DNS 服务的运营商都支持 DNSSEC，但实际使用该技术的域名却寥寥无几。

（二）DDoS 攻击：流量洪流中的服务器困境

DDoS（分布式拒绝服务）攻击是一种极具破坏力的网络攻击方式，它通过向 DNS 服务器发送大量的请求，如同汹涌的洪水一般，耗尽服务器的资源，使其无法响应合法的请求。这种攻击就像一场恶意的 “人海战术”，让 DNS 服务器在海量的非法请求中陷入瘫痪。

面对 DDoS 攻击，目前通常的应对方法是部署 DDoS 防护系统。该系统可以通过限制同时连接数以及流量等方式，对恶意请求进行过滤和限流，确保 DNS 服务器能够正常处理合法的请求。这就好比在服务器的入口处设置了一道坚固的防线，只有合法的请求才能顺利通过。

（三）随机非存在域名攻击：缓存穿透的隐蔽威胁

随机非存在域名攻击是一种较为隐蔽的攻击方式，攻击者通过递归服务器查询合法域名的随机子域名来实施攻击。从本质上讲，这是一种缓存穿透攻击，因为请求的域名实际上并不存在，递归服务器最终会将解析请求发送到权威 DNS 服务。

对于权威 DNS 服务器而言，如果其记录量相对较少，可以考虑采用全缓存的方式，将所有记录都放入内存中，这样可以快速响应查询请求。而如果记录量非常大，使用布隆过滤器则是一个不错的选择。布隆过滤器可以在占用较少内存的情况下，高效地判断一个元素是否存在于集合中，从而快速处理这类攻击请求。

对于递归解析服务器，由于难以区分正常的不存在域名查询和攻击行为，通常只能将这种情况当作 DDoS 攻击来处理，采取相应的流量限制和过滤措施。

（四）子域名劫持：配置疏忽引发的安全漏洞

子域名劫持涉及攻击者利用 DNS 提供商中配置错误的未使用子域名进行恶意操作。例如，许多服务都托管在云端，如果一个子域名曾经被使用并对外提供服务，但在服务下线时没有及时移除相应的 DNS 记录，那么同一个云上的其他用户就有可能使用与原服务相同的公网 IP。此时，该用户就可以在这个域名下搭建恶意功能，如钓鱼网站、窃取 Cookies 等，从而对用户造成严重的安全威胁。

为了防止子域名劫持，域名所有者需要采取一系列管理及技术手段。在服务下线时，务必确保域名解析也同时移除，避免留下安全隐患。同时，定期对 DNS 配置进行检查和审计，及时发现并修复可能存在的配置错误。

（五）DNS 劫持：篡改路径的恶意引导

DNS 劫持是指攻击者通过篡改 DNS 服务器的配置或添加虚假的 DNS 条目，将用户的请求重定向到假冒网站或恶意服务器。这种攻击方式就像在用户的网络导航图上做了手脚，将用户引导到错误的方向。

随着 HTTPS 的广泛普及，DNS 劫持的危害性大大降低。因为如果攻击者无法修改权威服务器上的解析记录，那么这种攻击的有效范围就会受到极大限制。在 HTTPS 连接过程中，证书验证机制可以检测到域名与证书不匹配的情况，从而提醒用户可能存在的风险。

为了防范 DNS 劫持，一方面要加强对 DNS 服务器的访问控制，确保只有授权人员能够对其进行配置修改。另一方面，要建立完善的监控机制，实时监测 DNS 配置的变化，及时发现并处理异常情况。同时，定期检查 DNS 配置和记录的完整性与准确性，确保其没有被篡改。

（六）中间人攻击：通信链路中的窃听者

中间人攻击是一种常见的网络攻击手段，在 DNS 领域，攻击者通常会劫持 DNS 通信，在 DNS 请求和响应之间插入自己的恶意程序，从而能够读取、修改或注入虚假的 DNS 数据。此外，一些运营商可能由于硬件资源不足，在支持 DNS 流量时，会导致 DNS 解析异常缓慢甚至超时，严重影响用户体验。

为了应对中间人攻击，使用加密协议（如 DoT 或 DoH）是非常有效的方法。这些加密协议可以确保 DNS 通信在传输过程中的安全性，使得攻击者无法轻易窃取或篡改数据。就如同在通信的道路上设置了一道加密的屏障，只有合法的通信双方能够穿越这道屏障进行安全的信息交流。

四、DNS 客户端安全性增强指南

（一）客户端软件供应商的安全策略

1. 加密协议的应用：使用加密协议是保护终端到本地 DNS 服务器之间通信安全的有效途径。像 OpenDNS、Google DNS、Cloudflare 等知名的 DNS 服务提供商，都推荐使用加密 DNS 协议。通过采用这些加密协议，客户端与本地 DNS 服务器之间的数据传输将得到加密保护，有效防止中间人攻击等安全威胁。这就好比为客户端与本地 DNS 服务器之间的通信搭建了一条安全的 “隧道”，数据在其中传输更加安全可靠。

2. HttpDNS 的使用：目前各大云服务提供商都提供了 HttpDNS 服务。对于客户端软件中用到的域名，通过 HttpDNS 来进行解析，可以绕过传统的 DNS 协议，从而规避所有针对 DNS 协议的攻击。这就如同为客户端软件开辟了一条专属的、更加安全的域名解析通道，确保关键域名的解析不受传统 DNS 安全问题的影响。

（二）客户端用户的安全实践

1. 浏览器设置安全 DNS：常用的浏览器如 Chrome、Edge、Firefox 等都支持设置安全 DNS。客户端用户可以在浏览器的设置选项中，选择使用安全的 DNS 服务。这样，在浏览网页时，浏览器发出的 DNS 查询将通过安全的通道进行，大大提高了上网的安全性。这就好比为浏览器安装了一个安全导航仪，确保用户在网络世界中航行时更加安全。

2. 本地搭建 DNS 代理：对于一些不支持安全 DNS 的软件，用户可以通过本地搭建 DNS 代理的方式，将 DNS 请求代理到 DoH 或 DoT 进行解析。这样一来，即使是原本不具备安全 DNS 功能的软件，也能够享受到安全的 DNS 服务。在企业内部，也可以采用这种方式为员工提供统一的安全 DNS 服务，提升整个企业网络环境的安全性。这就如同在本地建立了一个安全的 “中转站”，将所有的 DNS 请求都引导到安全的路径上进行处理。

利用大模型提升企业外网高危 WEB 服务识别效率与精度

Sat, 11 Jan 2025 20:36:25 +0800

引言

在企业安全能力建设的日常工作里，有效收敛企业外网高危资产，对保障公司外部安全起着关键作用。其中，WEB 高危服务（例如管理后台、内部系统等）向外开放所带来的风险，是企业面临的重大挑战。传统针对此风险的识别方式主要基于规则，然而，这种方式不仅需要投入大量人力成本用于规则维护，而且由于规则难以覆盖全面，常常出现误报、漏报等情况，导致实际效果欠佳。

借助 “文心大模型” 这一创新工具，企业仅需投入少量资源，便成功解决了高危 WEB 应用服务识别的难题，且准确率达到 70% 以上。本文将详细阐述这一创新性解决方案的原理、实践过程及效果。

传统高危 WEB 服务识别技术剖析

传统的高危 WEB 服务识别技术，是通过整合开源指纹库以及内部产品指纹维护，构建起企业指纹识别库。其核心原理是获取 WEB 应用的 Header、Body、Title、Banner 等信息，并与指纹库中的规则进行比对判别。为实现较好的检出效果，该模式需要持续扩充企业指纹库。

此技术架构主要包含三个层面：

1. 数据层：作为整个架构的基础，数据层承载着公司网络资产与指纹资产。其数据丰富程度，在很大程度上决定了 WEB 服务识别能力的成熟度与覆盖范围。

2. 扫描层：扫描层负责处理数据层的数据，将其解析为固定格式，作为扫描输入源。一般通过端口扫描模块对资产执行端口发现、服务识别以及 CPE 信息获取等操作。在获取有效资产数据后，向资产发起请求以获取服务信息，并与已有的指纹库进行对比判别。具体实现逻辑如下：

1. 利用 WEB 服务解析模块提取所有 WEB 资产的服务信息。

2. 将获取的 WEB 服务信息与指纹数据库进行比对，得出结果。

3. 传递并返回最终结果。

3. 业务层：业务层作为事件运营处置层，通常接收来自其他数据源的输入。安全运营人员对事件进行判别后，将其推送至业务方进行修复，从而完成事件的闭环处理。

高危 WEB 服务识别面临的挑战

从传统高危 WEB 服务识别方案中，我们不难发现存在以下几方面问题：

1. 规则维护的人力困境：检测规则依赖人工编写与维护，在人力资源有限的情况下，如何确保外网高危服务资产的风险得到有效收敛，成为一大难题。】

2. 未知服务的检测盲区：传统方式能够识别和发现已知框架与服务，并转化为检测规则，但面对未知服务或框架时，如何察觉潜在风险，是现有方案难以突破的瓶颈。

接下来，我们将探讨如何借助大模型能力，解决传统方案中的这些痛点。

基于大模型的高危 WEB 应用服务识别设计思路

大模型输入数据处理

在运用大模型识别高危 WEB 应用服务前，需精心规划模型的输入数据格式。从安全工程师的专业视角出发，判断一个 WEB 应用服务是否高危，主要依据 Title、Body、Header 这三类信息，其中 Title 和 Body 尤为关键。由于原始 HTML Body 中往往包含大量无用标签与数据，为保证模型输入数据的纯净度，需对其进行清洗。若原始数据存在较多脏数据，可能导致模型产生噪点，进而影响在真实场景下输出的稳定性。此外，考虑到输入的 Token 限制，还需对较大的原始 HTML Body 进行缩减，以满足 Token 要求

大模型判别规则制定

为使模型准确识别高危服务，前期需制定明确的判别规则，界定高危服务的范围。以下为部分判定案例：

1. 涉及系统管理功能的平台，视为高危服务。

2. 已知不应开放到外网访问的开源系统 / 框架，如 Kibana、ElasticSearch、Grafana、Nacos 等，判定为高危服务。

3. 无效页面、错误页面，如状态码为 404、500、502 的页面以及 nginx/centos 等默认页面，视为非高危服务。

4. 对外提供服务的常规页面，如百度智能云产品、百度网盘等 ToB、ToC 场景下的产品介绍页面，判定为非高危服务。

Prompt 构造技巧

在定义好判别规则后，需构造易于模型理解的 Prompt，引导大模型进行服务判别。Prompt 的质量直接影响大模型的性能表现。优质的 Prompt 上下文能够充分利用大模型的背景语料知识，使其在特定工作中发挥更佳。经实践观察，提炼出以下部分 Prompt 作为模型指导：

"现在有一份从网站首页提取的数据，请你根据这份数据判断该网站是否属于高危服务，并给出相应的判断理由。\n\n" +
"## 要求：\n" +
"1. 充分考虑数据中的每一个字段，敏锐发现可能象征风险的关键字。\n" +
"## 判断依据：\n" +
"高危服务主要指暴露后可能对公司信息系统造成危害的服务。\n" +
"1. 对于管理后台登录、控制面板、数据库面板等页面，应当判定为高危服务。\n" +
"非高危服务指正常对外开放，提供各类功能的服务。\n" +
"1. 对于常规的网站服务、普通用户登录等页面，判定为非高危服务。\n" +
"## 输出格式 \n" +
"{"reason":"< 判断为高危或非高危的具体理由>","isDangerous": <true 或 false>}\n\n\n\n\n"

输入数据源选择与扩充

在完成上述准备工作后，需挑选具有代表性的数据作为初始输入，用于基础模型的识别与训练。训练前期，从内部资产库中精心挑选 100 多条数据，涵盖常见的 WEB 应用框架（如 Grafana、ElasticSearch）、内部高危系统、常规百度对外服务以及通用管理后台页面等。在人工完成数据标记后，初步构建了一个数据源。

为进一步提升模型准确率，采用 self - instruction 方法扩充数据源。此方法借助语境学习（In - context Learning）原理，在 Prompt 中提供数个样例，依托大模型语言基座执行小样本学习。具体操作是对上述 Prompt 进行改造，构造几个预设的对话上下文，使大模型在已有几轮对话的基础上，对新内容进行生成。在此过程中，选用普适性高且性能优越的百度千帆 ERNIE 4.0 Turbo 旗舰模型。

模型微调优化

模型微调的数据量建议在 1k 条左右。本模型基于百度千帆平台进行训练，只需按照平台格式导出数据并进行训练。微调后的模型发布后，不仅回答准确性大幅提升，且能确保输出格式严格符合要求。

完成微调后，后续模型数据录入无需再依赖 Prompt Learning 等方式，可直接使用当前模型进行标注。经人工筛选后，重复训练以实现模型的强化学习。通过这一系列流程，可训练出精准度较高的模型，用于识别外部高危 WEB 应用服务。下面将介绍该模型在真实场景中的实践应用。

大模型高危 WEB 应用服务识别实践

实践架构解析

目前，该方案在公司场景中的架构主要分为两大部分：WEB 资产信息获取和大模型判别。

在服务识别流程的后续模块中进行调用，默认情况下，先对外网资产进行端口发现和服务识别，随后调用资产信息采集 Agent，解析 WEB 资产中的报文、标题等关键信息。经过数据清洗后，通过 API 接口直接对接后端大模型能力进行判定，并将判定结果推送至事件运营中心进行处理。

在模型应用前期，基于人工运营数据对大模型的 Prompt 进行调整，以获取更精准的 Prompt，助力模型提升准确率。经过几轮迭代优化后，模型在无人监督的情况下也能达到较好的精度。以下为训练后实际发现的高危 WEB 应用服务案例展示：

后续迭代优化策略

在前期投入精力获得高精度模型后，后期持续运营迭代过程中，仅需投入少量人力对识别结果进行复核，针对偏差数据进行微调，即可不断提升模型准确率。具体流程如下：在后期人工标记过程中，定期对模型的训练数据进行纠正标记；积累一定数量的数据后，对模型进行微调，以此避免因标记数据不足导致的模型微调效果不佳问题。

后记

在实际安全应用场景中，基于大模型的方法通过较少的数据集，成功训练出效果良好的模型。目前，该模型能够较为精准地判别 WEB 服务是否为高危应用，准确率达到 70%。在实际应用中，成功发现众多业务方管理后台服务和测试环境等高危应用场景外开的情况，有效解决了前文提到的两大难题。在人力资源有限的情况下，只需定期投入部分人力对模型进行标记调整，无需再耗费大量精力维护指纹规则库，便可取得显著成效。

然而，该方案也面临一定挑战。由于大模型缺乏先见知识，在部分场景下，如 ToB 交付业务服务需开放在公网供客户使用的情况，大模型的识别精准度有待进一步提升。未来，仍需持续投入人力完善模型训练，以解决此类场景下的问题，推动企业外网高危 WEB 服务识别技术的不断进步。

一次 Go 编译问题的排查与解决历程

Fri, 10 Jan 2025 21:14:09 +0800

在软件开发的世界里，从开发环境到生产环境的迁移过程中，常常会遇到各种意想不到的问题。今天，就让我们一起走进洞源实验室 INSBUG 的开发者在 2024 年 10 月 8 日遇到的 Go 编译问题的解决之旅。这位开发者在本地 Windows 环境下精心打造了一个 Go 语言小项目，经过细致的单元测试和集成测试，一切都顺利通过，满心欢喜地准备将项目部署到 VPS 服务器上自动运行。然而，当在服务器上执行 `go run` 命令时，程序却如同一潭死水，没有任何响应和回显，就连 `main` 函数开头的 `fmt.Println()` 语句都石沉大海，毫无输出。面对两个环境下相同程序却产生不同执行结果的情况，经验告诉我们，问题往往出在配置或者环境方面。于是，一场有条不紊的排查之旅就此展开。

一、配置检查开发者首先对本地和服务器的 Go 语言配置以及模块配置进行了细致的比对。其中，Go 语言版本存在细微差异，本地是 1.22.4 版本，服务器则是 1.23.0 版本。为了确保模块的一致性，开发者执行了 `go clean -modcache` 和 `go mod tidy` 命令，重新拉取了涉及的模块。但遗憾的是，问题依旧顽固地存在着。

二、单元测试排查接着，开发者将目光投向了程序中的单元测试文件。当单独执行 `go test -v` 命令时，同样没有任何输出，这表明单元测试文件在执行时也遭遇了相同的困境。起初，怀疑的矛头指向了模块引用路径、程序中的路径或者程序在 Linux 下的权限设置等方面。然而，单元测试执行出现的问题却巧妙地排除了模块引用和路径问题，问题的线索逐渐聚焦到程序中与数据库操作相关的函数上。

三、代码排查定位为了揪出问题的根源，开发者采用了分步注释和执行主程序的方法，逐步确定导致程序无响应的代码块。经过一番艰苦的排查，最终发现问题的症结在于 `import modernc.org/sqlite` 这一行代码。这是一个用于操作 SQLite 数据库的第三方模块，由 Go 语言编写，按常理来说，不应存在环境兼容问题。为了进一步查明原因，开发者单独编写了一个验证程序：

当通过 `go run` 单独执行这个测试程序时，同样的问题再次出现。紧接着，开发者通过 `go build -v` 手动编译，试图检查模块引入过程中的问题。然而，编译过程却意外终止，显示 `modernc.org/sqlite/lib: /usr/local/go/pkg/tool/linux_amd64/compile: signal: killed`。这意味着在编译 `sqlite` 模块的过程中，编译进程被无情地杀死，进而导致后续程序无法执行。

四、资源分析

为了弄清楚编译进程为何会被杀死，开发者借助 `htop` 工具对编译过程中的编译进程和系统资源情况进行了深入检查。随后，通过 `dmesg | grep -i ‘killed’` 命令，发现原来是内存不足（Out of memory）问题导致了进程被杀死，这与 `htop` 工具显示的内存使用情况完全吻合，VPS 服务器的内存仅有 500Mb，Swap 空间也只有 265Mb，实在是捉襟见肘。

五、解决之道

既然找到了问题的根源，那么对应的解决思路也就呼之欲出，主要有以下两种：增加内存由于服务器本身物理内存有限，增加内存的可行办法就是扩充 Swap 空间。具体操作如下：

1. 使用 `fallocate -l 1G /swapfile` 命令创建一个大小为 1G 的新 Swap 文件。

2. 通过 `chmod 600 /swapfile` 命令设置该文件的权限。

3. 执行 `mkswap /swapfile` 命令将该文件格式化为 Swap 文件。

4. 最后使用 `swapon /swapfile` 命令启用这个新的 Swap 文件。

此外，为了让新的 Swap 文件在系统启动时能够自动加载，还需要编辑 `/etc/fstab` 文件，并添加 `/swapfile swap swap defaults 0 0` 这一行命令。

完成上述配置后，重新在测试代码目录下执行 `go build -v`，便可以顺利完成编译过程。从 `htop` 对资源利用的观测结果来看，实际编译 `modernc.org/sqlite` 模块至少需要 1G 的内存。

六、交叉编译

交叉编译是另一种巧妙的解决方案，它允许在 Windows 系统上编译适用于 Linux 系统运行的可执行文件，充分利用 Windows 系统的强大性能来完成编译工作，然后直接在 Linux 系统上运行编译好的可执行文件。要进行交叉编译，需要设置 Go 语言的环境变量 `GOOS` 和 `GOARCH`。其中，`GOOS` 用于指定系统类型，如 `windows`、`linux` 等；`GOARCH` 用于指定架构类型，如 `amd64`、`arm` 等。由于开发者使用的本地 Windows 环境和 VPS 服务器都是 `amd64` 的 64 位系统，因此只需设置系统类型即可，执行命令 `go env -w GOOS=linux`。之后，再执行 `go build` 命令创建可执行文件，最后将这个可执行文件上传到 VPS 服务器上执行，便大功告成。通过这次对 Go 编译问题的深入排查与解决，不仅成功地将项目部署到了 VPS 服务器上，也为今后应对类似的问题积累了宝贵的经验。在软件开发的道路上，每一次问题的解决都是一次成长的契机，让我们能够更加从容地面对未来的挑战。

Sysmon高CPU和内存占用问题的深度剖析与解决

Fri, 10 Jan 2025 21:03:40 +0800

一、背景在近期的项目中，我们引入了sysinternals开发的监控工具sysmon.exe。然而，用户反馈在特定条件下，sysmon.exe进程（以下简称sysmon）会出现异常资源占用情况。具体表现为，sysmon会持续占用CPU，通常会跑满一个逻辑核。例如，在双核4线程的CPU环境中，sysmon的占用率可达25%。同时，其内存占用也呈持续上升趋势。本文所展示的图片均在调试环境中随文章编写截取，因此各位看到图中sysmon进程的PID可能不一致。

二、问题定位与分析问题初步定位

借助ProcessExplorer工具，我们深入观察sysmon进程各线程的CPU使用情况。结果发现，单个线程的CPU占用率并不高，但却出现大量新线程不断创建，同时大量旧线程被销毁的现象。这表明，CPU时间片主要被消耗在线程的创建与销毁操作上。与此同时，我们对sysmon的句柄使用情况进行观察，惊讶地发现句柄数量在极短时间内竟达到万级规模，呈现出异常增高的态势。

基于以上发现，后续的分析重点将围绕线程的频繁创建与销毁以及句柄的异常创建展开。调试器中定位问题 I. 定位线程大量创建销毁的问题从图2中我们注意到，所有创建的线程均以sysmon.exe + 0x494a8这个地址作为起始点。沿着这一线索深入挖掘，我们发现sysmon + 0x495aa这个堆栈返回地址，恰好位于sysmon.exe + 0x494a8函数的范围内。通过对sysmon + 0x495aa栈回溯线索的逐步追踪，最终确定sysmon + 0x1820e为问题函数。以下是sysmon各个子线程的栈回溯图：

在这一步分析完成后，我们先暂时搁置，稍后再对分析结果进行验证。接下来，我们将关注点转向内存占用过高的问题。 II. 定位内存占用过高问题从图3可知，sysmon在短时间内创建了大量句柄。在调试器中进一步查看这些句柄的使用情况，我们得到以下信息：

由上图可见，短短几分钟内，句柄数量从图3的4.5万多个急剧增加到72942个。其中，Event类型的句柄多达72878个，占比高达99%。并且这些Event都需要人工重置状态，这意味着在程序未对这些Event状态进行人工重置前，它们不会被释放。如此大量的Event在短时间内被创建且未释放，随着时间推移，内存占用自然会不断攀升。在调试器中确认问题 I. 内存占用过高问题的确认经过上一节的分析，我们初步确定了CPU和内存占用过高的原因。接下来，我们需要进一步验证这一结论。由于刚刚分析完内存占用过高问题，我们就从这里入手。熟悉Windows编程的人都知道，创建Event通常会调用CreateEvent函数。因此，我们在该函数上设置断点，具体设置如下：这个断点的含义是：首先在kernel32.dll中的CreateEventW函数调用起始位置中断，然后打印堆栈调用信息，最后恢复程序执行。以下是部分执行结果：

上图展示的是程序执行约5秒钟后的情况。从右侧下拉条可以看出，输出内容约有几千条，这意味着在5秒钟内创建了几千个Event，与我们之前观察到的句柄暴增现象相符。仔细查看每次栈回溯输出，我们发现都是由sysmon + 0x181b7附近触发了CreateEventW的调用。这里先留个悬念：注意OpenTraceW函数。同时，我们还需留意图6中最后一个sysmon模块的函数调用返回地址：sysmon + 0x181b7。结合图4中我们定位到的导致新线程不断创建的地址sysmon + 0x1820e，二者距离非常近。至于它们之间的因果关系，我们将在下文详细分析。 II. 线程大量创建销毁的问题的确认刚才提到sysmon + 0x181b7与sysmon + 0x1820e两个地址相近，通过下图，大家可以更直观地感受它们之间的距离：

基于目前所掌握的信息，整个问题的逻辑可能是这样的： 1. 系统中出现大量线程创建的情况。 2. 新创建的线程又大量创建了Event。 3. 创建的线程虽然退出，但由于Event需要手动重置，所以并未被释放。天下没有免费的午餐，如此大量的Event必然需要占用内存空间。因此，大量线程创建导致CPU使用率升高，大量未释放的Event则导致内存使用率上升。看到这里，可能有人会质疑，上述内容只是猜测，有什么证据支持吗？接下来，我们将在调试器中验证这一猜测。在正式开始验证之前，先阐述一下验证思路：根据前面的分析结论，新创建的线程会导致新创建Event。所以，如果我们在sysmon + 0x1820e处设置一个断点，在系统的CreateEventW函数上再设置一个断点，那么这两个断点应该会交替命中。由于这两个断点，一个位于sysmon模块的线程函数处，另一个位于系统的kernel32.dll模块地址，它们理论上并无必然联系。如果实际现象是两个断点交替命中，那么就可以验证我们之前的猜测。以下是实际操作过程，首先展示两个断点的设置情况：

解释一下，每行最开始的数值是断点编号，0代表0号断点，1代表1号断点；e表示两个断点均处于激活（enable）状态；后面的kernel32!CreateEventW和sysmon + 0x1820e分别代表断点的地址（具体分析见上文）；最后双引号里以.echo开头的部分表示，一旦命中该地址的断点，就打印当前断点的编号与堆栈调用关系，然后恢复执行。以下是断点命中的情况：

可以看到，实际现象与我们设想的一致，这进一步印证了我们猜测的正确性。或许仍有较真的读者认为，目前这些都只是间接证据。那么，接下来我们将直面问题，用代码来揭示真相。

出现此问题的根本证据上文中提到的两个地址（sysmon + 181b7与sysmon + 1820e）均位于函数sysmon + 0x180E0中。下面直接给出该函数的伪代码：

这里说明一下关键逻辑，请注意图10中的第44行处的函数调用sub_140018360，以及本函数的地址sub_1400180e0。这段代码的含义是，在某个全局信号的作用下，有可能会调用sub_140018360这个函数，并向其传递参数1。接下来，我们看看sub_140018360函数的具体功能，为了便于说明问题，对伪代码做了部分折叠处理：

请注意第69行的线程创建函数，也就是说，当sub_140018360函数的参数为1且不出现错误时，会执行到第69行的线程创建操作，而线程的入口函数正是sub_1400180e0。是不是感觉很眼熟？如果不熟悉，请回看上图10。这意味着sub_1400180e0最终会调用sub_140018360函数，而sub_140018360函数内部又创建了一个线程，该线程再次调用回sub_1400180e0函数。从图6的分析可知，正是由于sub_1400180e0里面的OpenTraceW函数导致创建了大量的Event，从而使得内存急剧上升。这是一个类似递归调用的逻辑，如果一直持续下去，将永无止境。至此，我们已经清晰地明确了问题所在。为了获取某种Trace的结果（上文提到的OpenTraceW函数），sysmon采用了类似递归的逻辑，不断重试以尝试获取结果。正是由于： 1. 递归调用创建线程，导致CPU使用率急剧飙升。 2. 上述创建的线程通过OpenTraceW创建了大量Event，导致内存占用飙升。至此，sysmon占用高CPU和高内存的直接原因已被成功找到。三、什么原因导致的此问题的产生在调试过程中，我们发现了以下几个关键现象： 1. sysmon会经历一次重启，且仅在重启后才会出现高CPU和内存占用的情况。 2. 在sysmon重启前，TsService.exe会启动几个进程，但这些进程很快就结束了。此时，可能大家心中会有疑问，TsService.exe究竟是什么呢？答案是，它是QQ浏览器的后台服务进程。以下是相关证据（该可执行文件具有正常的腾讯签名）：

随后，我们进一步跟进了TsService.exe启动的几个进程具体是什么：顺便提一下，图13中第一行未截全的部分是：set - default - browser --slient ; -）。接下来才是我们重点关注的内容，即几个xperf子进程的命令。在此，插入一个题外话。在解决这个问题查阅资料的过程中，我们发现了一篇名为《QQ浏览器性能提升之路 - windows性能分析工具篇》的文章。这篇文章详细解释了图13中xperf命令的含义：

同时，文章还提到了一些在使用过程中遇到的坑：

文章指出，ProcessMonitor和ProcessExplorer会导致xperf失败，需要先关闭它们再启动xperf。经过我们的测试，sysmon同样会导致xper.exe抛出与上图相同的错误。再补充一个知识点，xperf是微软官方提供的性能信息收集工具，借助它可以深入分析Windows系统上程序的多种性能问题。回顾本节开头提到的两个现象，sysmon重启后出现高占用现象，难道这与腾讯浏览器启动的xperf存在关联？四、此问题在任意机器上的复现为了验证上述猜测，我们进行了如下实验。首先直接公布结论，通过xperf和sysmon的“协同配合”，可以在任何机器上复现sysmon高CPU和内存占用的问题。具体操作步骤如下： 1. 首先，准备一个全新安装的纯净系统（此步骤可选）。 2. 在系统上安装sysmon服务，具体操作是在管理员权限的cmd下执行：sysmon -i。 3. 停止sysmon服务（因为不停止会导致xperf命令报错）。 4. 使用xperf.exe依次执行如下命令：

5. 重新启动sysmon服务。完成上述步骤后，新启动的sysmon服务的CPU使用率会占满一个逻辑核，内存使用率也会逐渐上升。如果在sysmon的CPU使用率升高后，再次执行：

则sysmon的使用率将降回到正常水平。五、谁关闭了sysmon？通过前面的分析我们知道，此问题的根本原因在于sysmon重启后，其所需的资源（NT Kernel Logger）被占用，导致重启后的sysmon服务无法获取所需资源，从而不断重试。那么，究竟是什么原因导致sysmon退出呢？结合上文分析，我们将排查重点放在了TsService.exe服务上。通过对TsService.exe进程的OpenServiceW函数设置断点，最终将问题锁定在PerfTool.dll这个模块上：

六、此问题的解决方案（部分） I. 方案一请注意，这里只是基于上文分析提出的几种解决方案，并非最终的唯一解决办法。从图10中的第43和44行可知，在调用导致“递归”的函数之前，存在一个if判断。该判断使用sub_14008da0（我们已将其重命名为fnReadRegistryValue）的返回值与1进行逻辑与操作，只有当该操作为真时，才会触发“递归”逻辑。接下来，我们看看fnReadRegistryValue这个函数的具体功能：

可以看到，该函数的返回值为Data，而Data中的数据来源于注册表的如下键值：

如果此键值的值与1做与运算结果为0，即可终止“递归”逻辑。也就是说，如果这个键值下的数值为偶数，那么就永远不会因为这两个函数的“递归”调用而产生高CPU和内存占用的问题。那么这个键值有什么作用呢？从sysmon的帮助文档可知，sysmon是一个命令行工具，具备启动参数。结合Options的含义，我们知道不同的sysmon监控启动参数会导致这个值发生变化。后续实验也证实了这一点，该键值的确会根据sysmon的启动参数不同而改变。因此，一个可行的解决方案是，当发现CPU占用过高且内存缓慢上升时，可以暂时将该键值设置为0，使程序跳出“递归”逻辑，之后再将该值恢复为原来的值，以避免影响其正常监控功能。 II. 方案二从图16可知，TsService.exe关闭sysmon采用的是硬编码方式。而sysmon在安装服务时，支持使用其他服务名。所以，另一个可行的解决方案是在安装sysmon服务时，选用其他服务名，从而防止被TsService.exe关闭。

七、总结正如本文所剖析的性能问题一样，原本旨在进行性能排查的操作，却最终引发了性能问题，进而需要进一步对该性能问题展开排查。而此问题的产生并非单一因素所致，而是多种因素共同作用的结果。由于性能测试具有一定的特殊性，并非所有机器都需要执行此项测试。因此，初始化过程中的关闭sysmon、启动xperf进行性能信息收集这一操作，并不会在每台机器上执行。所以，这个问题的出现具有一定的“随机性”，并非在每台机器上都会出现。通过对这一复杂问题的深入分析与解决，我们不仅成功找到了sysmon高CPU和内存占用问题的根源，还提出了相应的解决方案，为今后处理类似问题积累了宝贵经验。

守护我们网络安全的正义侠客

Thu, 09 Jan 2025 14:34:15 +0800

打破刻板印象：认识不一样的黑客

在大众的普遍认知里，“黑客” 这个词往往带着几分神秘与危险的色彩。提起黑客，许多人脑海中首先浮现的，或许是电影中那些在昏暗房间里，对着电脑屏幕疯狂敲击键盘，凭借高超技术突破重重防线，肆意攻击系统、窃取机密信息的神秘身影。就像在经典的谍战电影里，中情局系统惨遭黑客入侵，大量特工计划和机密信息泄露，引发了一系列惊心动魄的危机，让观众对黑客的 “破坏力” 有了直观感受。现实生活中，类似索尼影业遭遇 “黑客门”、不法分子利用黑客技术盗取影视资源等事件，也时有发生，进一步加深了人们对黑客群体的负面印象。

然而，黑客群体绝非如此单一、负面。实际上，他们就像一个神秘的多面体，有着诸多不为人熟知的一面。在网络的浩瀚海洋中，存在着这样一群黑客，他们以技术为剑、以正义为盾，默默守护着网络世界的秩序，为我们的数字生活保驾护航。他们被称为 “白帽黑客”，是网络安全的守护者，与那些作恶的 “黑帽黑客” 截然不同。如今，是时候打破刻板印象，走进这个神秘群体中正义的一方，去探寻他们背后的故事了。

白帽黑客：企业网络的 “守护神”

白帽黑客，作为网络世界中的正义使者，肩负着守护企业网络安全的重任。他们运用自己精湛的技术，模拟黑客攻击的手法，对企业的网络系统、应用程序等进行全面、深入的 “体检”，挖掘潜在的安全漏洞，为企业提前拉响警报。

以知名白帽黑客吴翰清为例，他在 20 岁时，就凭借着卓越的黑客天赋，在面试中仅用三分钟，便成功突破了一家科技公司的局部内网，让面试官惊叹不已，当场签约，成为这个公司最年轻有为的网络安全技术人员。当时的阿里巴巴，每天面临着来自黑客的高达 3 万次攻击，形势岌岌可危。然而，吴翰清宛如一道坚不可摧的防线，多次成功抵御黑客的猛烈进攻，为公司筑起了稳固的安全壁垒。在他的守护下，这个公司的网络系统得以稳健运行，用户数据安然无恙，他也因此赢得了极高的赞誉，成为业内的传奇人物。

还有胡建钧，作为某公司在中国首席网络与信息安全官，他从实习生起步，一路成长为网络安全领域的领军人物。他带领团队，像一群敏锐的侦探，每天仔细查看安全事件记录，追踪最新的安全前沿动态。他们的工作就像是一场与黑客的赛跑，要抢在黑客之前，通过模拟攻击找到系统的薄弱环节。一旦发现漏洞，便迅速通知相关部门进行修复，为这个公司在中国乃至全球的业务保驾护航。在他们的努力下，这个公司的基础设施及产品犹如穿上了坚固的铠甲，让网络犯罪分子望而却步。

他们的事迹正如正义的侠客一般为我们解决了许许多多的不法黑客的攻击，同时也为我们的网络安全保驾护航，我们现在的网络通畅安全离不开他们的守护。

从边缘到变革引领者

Wed, 08 Jan 2025 15:33:50 +0800

在大众想象里，黑客常隐匿于阴影，手指如飞敲代码，行神秘莫测之事。但在技术革新的浪潮中，部分黑客正走出刻板印象，以创新思维和精湛技艺，成为推动社会进步的积极力量。

科技发展日新月异，医疗领域也面临数字化转型的挑战。黑客凭借对数据和算法的精通，悄然助力医疗变革。他们开发创新软件，优化医疗数据管理。传统医疗数据分散、格式繁杂，给研究与诊断带来困难。黑客打造的智能系统，能整合各类数据，运用人工智能算法分析，辅助医生快速准确诊断。例如，通过分析大量病例影像与诊断结果，算法可识别疾病早期特征，帮助医生及时发现病症，挽救患者生命。

教育领域同样能看到黑客的身影。他们打破传统教学资源的局限，利用网络技术搭建在线学习平台。这些平台汇聚全球优质教育资源，无论身处偏远山区还是繁华都市，学生都能按需学习。一些黑客还开发了互动性强的学习软件，通过游戏化、情景化教学，激发学生学习兴趣。比如编程学习软件，以闯关游戏形式让学生在实践中掌握编程知识，让学习不再枯燥。

当自然灾害来袭，基础设施遭受破坏，通信中断，常规救援手段受阻。这时，黑客凭借对通信技术和网络架构的深入理解，迅速搭建临时应急通信网络。他们利用无线电设备、卫星通信技术及开源软件，构建起数据传输通道，使灾区与外界恢复联系。在地震灾区，常规通信基站倒塌，黑客团队利用自制的简易通信设备和开源网络协议，实现了灾区内部及与外界的基本通信，为救援物资调配、医疗救助指导提供了关键信息支持。

在环保领域，黑客也有独特贡献。他们通过编写代码，分析海量环境数据，监测环境污染情况。借助物联网技术，收集大气、水、土壤等环境传感器数据，运用算法精准定位污染源。同时，开发环保类应用程序，引导公众参与环保行动。如开发碳足迹计算软件，帮助个人和企业了解自身碳排放情况，制定减排计划。

尽管黑客群体常因少数不法之徒而被误解，但这些在各领域积极作为的黑客，正重塑大众认知。他们以技术为画笔，在不同领域描绘创新蓝图，推动社会进步。随着科技发展，他们将在更多领域施展才华，带来更多积极改变。