汽车渗透测试自动化工具和过程，零基础入门到精通，收藏这篇就够了-优快云博客

摘要

当前，汽车行业致力于将安全性融入车辆开发流程。在此过程中，需对车辆可能面临的安全威胁进行分析，以便制定安全方案或安全措施。车辆安全开发中的另一个重要方面是安全测试，渗透测试常被用于此目的。在渗透测试中，测试人员会从攻击者的角度出发，通过攻击（测试）尝试破坏车辆的安全属性，以发现潜在漏洞。由于这项工作通常是在对系统了解有限的情况下进行的黑盒测试，因此渗透测试是一项高度依赖经验的活动，这使得该过程的自动化难以实现。在本文中，我们希望通过扩展我们的汽车端口扫描工具来支持渗透测试过程及其自动化。该扫描工具旨在扫描与典型信息技术（IT）网络不同的车辆网络，以提取车辆相关信息。我们的工具能够收集车辆中安装的电子控制单元（ECU），以及这些单元提供的诊断服务和子功能。此外，该工具还新增了自动检测车辆中使用的传输协议和诊断协议的功能。借助这些信息，能够实现新的用例和功能，例如模糊测试或渗透测试用例的自动生成。

1、引言

当前，汽车行业正朝着自动驾驶的方向发展。这一趋势使得车辆中安装的传感器和执行器数量不断增加，同时也提高了车辆组件内部和外部通信的复杂性。自动驾驶所需的对外通信增加了安全攻击的风险，多个研究团队的研究已经证明了这一点。研究人员对车辆发起攻击，成功操控了会影响行驶物理特性的执行器，如转向和制动系统。由于汽车领域目前用于防范此类攻击的方法有限，因此目前在安全措施、标准和流程的研发方面投入了大量精力。汽车开放系统架构（AUTOSAR）开发伙伴关系提出了一种通过安全车载通信（SecOC）保护车辆内部网络的措施，该措施能够实现车辆内部总线系统的认证通信。2016 年 1 月，国际汽车工程师学会（SAE）发布了 SAE J3061《网络物理车辆系统网络安全指南》，该指南将安全性融入了车辆开发流程。在此流程中，需对车辆可能面临的安全威胁进行分析，以便制定安全方案或安全措施。车辆安全开发中的另一个重要方面是安全测试，除了验证已实施的安全措施外，还包括测试车辆是否存在漏洞。渗透测试常被用于此目的。在渗透测试中，测试人员会从攻击者的角度出发，通过攻击（测试）尝试破坏车辆的安全属性，以发现潜在漏洞。渗透测试既可以在不了解系统内部功能的情况下以黑盒测试的形式进行，也可以在了解系统内部功能的情况下以白盒测试的形式开展。尤其是在黑盒测试中，由于对系统的了解有限，渗透测试的成功与否很大程度上取决于测试人员的经验。

1.1 问题

渗透测试可能会耗费大量时间，并且能否发现潜在漏洞还取决于所能获取的系统信息。它是一种探索性的测试方法，高度依赖测试人员的经验，这使得该过程的自动化难以实现。

1.2 方法

我们提出了一种基于工具的解决方案来支持渗透测试过程。该方案以我们过去推出的汽车端口扫描工具为基础。由于车辆网络在使用的通信技术、协议和操作系统方面与 IT 网络存在差异，因此专门开发了这款扫描工具来扫描车辆网络。该工具用于支持信息收集过程，能够收集车辆中安装的电子控制单元（ECU），以及这些单元提供的诊断服务和子功能。

1.3 贡献

我们为端口扫描工具新增了自动检测传输协议和诊断协议的功能，这一功能能够提供更多关于车辆及其内部结构的信息，从而在提取车辆数据时实现更大范围的覆盖。通过介绍借助车辆传输协议和诊断协议相关信息可实现的用例，我们展示了该功能如何为渗透测试子过程的自动化提供支持。因此，能够实现新的功能，例如基于这些传输协议和诊断协议的自动化攻击测试或模糊测试。

本文的结构如下：在第二部分，我们将讨论现有的车辆网络通信系统以及相关的传输协议和诊断协议，此外还将介绍基本的渗透测试流程以及针对汽车领域的调整。在第三部分，我们将介绍汽车端口扫描工具，以及为实现自动协议检测而对其进行的扩展和由此产生的用例，同时还将说明如何自动检测电子控制单元（ECU）、传输协议和诊断协议。为了说明该工具如何为自动化渗透测试提供支持，我们将在第四部分介绍通过自动协议检测可实现的各种功能。最后，在第五部分总结研究成果，并阐述未来的工作计划。

2、背景

在本节中，我们将简要概述车辆网络及其通信系统，以及渗透测试流程和该流程在汽车领域的实施方式。

2.1 车辆网络协议

开放系统互连（OSI）层模型用于对通信系统进行结构化描述，该模型描述了七个不同的层级，每个层级都包含消息传输的特定任务。由于我们重点关注汽车通信系统的传输协议和诊断协议，因此与我们研究目的相关的层级包括：物理层（第 1 层）、数据链路层（第 2 层）、传输层（第 4 层）和应用层（第 7 层）。第 1 层和第 2 层由所使用的通信系统体现。车辆中存在多种通信系统，如 FlexRay、控制器局域网（CAN）、本地互连网络（LIN）、以太网（Ethernet）和面向媒体的系统传输（MOST）。这些系统适用于不同的应用场景，并且具有不同的特性。FlexRay 是一种循环网络通信系统，适用于对数据速率要求较高（10 Mbit/s）的应用场景。MOST 和以太网主要用于对数据速率要求更高的多媒体应用。LIN 是一种串行网络协议，用于连接传感器和电子控制单元（ECU）等组件。在汽车领域，CAN 是最重要且最常用的总线系统之一。它是一种基于位流的总线系统，使用双绞线作为物理介质。CAN 是一种广播式系统，每个消息都由一个唯一的标识符来标识。由于 CAN 目前是汽车领域最常用的总线系统，因此在自动协议检测方面，我们首先将重点放在 CAN 上。为了说明该机制的功能，本文将重点介绍基于 CAN 的传输协议和诊断协议。

传输协议对应 OSI 层模型的第 4 层。当需要传输的数据大于消息最大长度时，就需要使用传输协议，这在诊断应用和电子控制单元（ECU）的闪存编程中尤为必要。传输协议的另一项任务是控制各个数据包之间的时间间隔。此外，传输协议还用于通过网关将消息转发到具有不同地址空间的网络。常用的传输协议包括标准化的国际标准化组织传输协议（ISOTP）和 SAE J1939，以及汽车制造商大众汽车公司的专有协议 —— 传输协议（TP）2.0。ISOTP 和 TP 2.0 适用于乘用车，而 SAE J1939 协议则用于商用车。

应用层由诊断协议体现。诊断协议使用所谓的服务标识符（SID）来选择电子控制单元（ECU）提供的不同诊断服务。为了理解其功能，图 1 展示了其通信原理。外部诊断测试设备作为客户端运行，而电子控制单元（ECU）则作为服务器运行。要启动诊断通信，诊断测试设备必须向电子控制单元（ECU）发送诊断请求消息。该请求包含一个服务标识符（SID）和一个子功能，子功能对于调用诊断服务（如读取故障存储器）是必不可少的。被请求的电子控制单元（ECU）可以返回肯定响应或否定响应。肯定响应的特征是在服务标识符（SID）的基础上加上数值 0x40。否定响应的特征是包含错误标识符（0x7F）、原始服务标识符（SID）以及包含否定原因的响应代码。

图1、汽车诊断协议的请求和响应方案

以下三种诊断协议具有重要意义：关键字协议（KWP）2000、统一诊断服务（UDS）和车载诊断（OBD）。这些协议均已标准化，且彼此之间具有相似性，因为它们都遵循图 1 所示的通信原理。

综上所述，车辆网络中存在三个相关组件：通信系统、传输协议和诊断协议。传输协议嵌入在通信系统消息的数据字段中，而诊断协议则嵌入在传输协议中。

2.2 渗透测试

渗透测试在运行中的系统上进行，并且通常在开发周期的后期阶段开展。由于测试人员不了解系统的内部功能，因此这些测试通常以黑盒测试的形式进行。基于此，测试人员会从攻击者的角度出发开展测试工作。目前已发布了多项用于实施渗透测试的标准和指南。纯粹的渗透测试标准可被视为安全评估方法的一部分，而安全评估方法则是对系统或企业的安全性进行全面评估。安全评估指南的示例包括美国国家标准与技术研究院（NIST）的 SP 800-115《信息安全测试与评估技术指南》、开源安全测试方法论手册（OSSTMM）3、信息系统安全评估框架（ISSAF）以及开放 Web 应用程序安全项目（OWASP）测试指南。纯粹的渗透测试标准示例包括渗透测试执行标准（PTES），该标准旨在支持企业和安全服务提供商实施渗透测试。

研究中提出了一种汽车领域的安全测试方法，即汽车安全测试方法（ASTM），该方法分为五个部分：规划阶段、检测阶段、安全状态分析、行驶中车辆分析、文档记录与审查。该方法涵盖了上述方法中的典型阶段，并将这些阶段应用于汽车领域，尤其是控制单元的车辆网络。我们的端口扫描工具可作为信息收集阶段（检测阶段）的示例工具。

其他研究也涉及了车辆渗透测试。拜耳等人将渗透测试视为实际汽车安全测试的一部分。在文献中，他们将渗透测试归类为与功能测试、模糊测试和漏洞测试并行的测试方法，同时区分了硬件、软件、后端和网络渗透测试，并考虑了组织方面的因素。在文献中，拜耳等人提出了一种基于上述研究的 CAN 网络渗透测试框架实现方法，该方法为渗透测试人员提供了一种系统化的方法。他们通过两个示例演示了该方法，即在示例中对 CAN 标识符进行逆向工程，并利用 UDS 诊断命令。史密斯提出了另一种渗透测试方法。波佐邦和辛佐夫对现有的 CAN 工具进行了概述。此外，杜尔旺等人通过系统化的渗透测试流程发现了安全气囊电子控制单元（ECU）中的一个漏洞，并强调了渗透测试在汽车领域的作用。

3、方法

在本节中，我们将介绍汽车端口扫描工具，以及为实现车辆网络协议自动检测而对该工具进行的扩展。

3.1 汽车端口扫描工具

该端口扫描工具的用途是检测车辆中的电子控制单元（ECU），搜索这些单元提供的诊断服务和子服务，以及从电子控制单元（ECU）中获取特定数据。用户在使用该工具时无需了解任何制造商特定信息，并且该工具既可以连接到车载诊断（OBD）接口（如图 2 所示），也可以直接连接到总线系统。

图2、端口扫描工具向汽车发送诊断请求，以收集ECU及其诊断服务和子服务

在使用端口扫描工具时，第一步是采用穷举搜索法检测车辆网络中的所有电子控制单元（ECU）。为此，会按照国际标准化组织（ISO）14229 中定义的标准诊断请求，向每个可能的 CAN 标识符（ID）依次发送请求。如果收到对某个请求的响应（无论是肯定响应还是否定响应），则表明识别到了一个电子控制单元（ECU）。

第二步是识别受支持的诊断服务。与之前识别电子控制单元（ECU）的过程类似，通过向每个已检测到的电子控制单元（ECU）发送诊断请求，来检查每个可能的服务标识符（SID）。如果某个请求收到了响应（无论是肯定响应还是否定响应），则表明对应的服务是受支持的。

第三步是识别所有已发现诊断服务的子服务。通过向每个电子控制单元（ECU）的每个受支持服务的所有可能子服务发送诊断请求，来实现对子服务的识别。

该端口扫描工具面临的一个挑战是车辆网络中可能使用的传输协议存在差异。法律规定，在诊断过程中必须使用结合了车载诊断（OBD）的国际标准化组织传输协议（ISOTP）。然而，诊断标准中为汽车制造商预留了特定领域。例如，大众汽车集团（Volkswagen AG）的车辆在这些诊断请求中使用了传输协议（TP）2.0 等传输协议。

文献中给出了该端口扫描工具当前功能的一个示例，该工具在两辆车上进行了应用测试。在第一辆车上，该端口扫描工具在 48 分 27 秒内找到了 47 个电子控制单元（ECU）、380 项诊断服务和 1924 个子服务。在第二辆车上，该工具在 36 分 05 秒内找到了 43 个电子控制单元（ECU）、282 项诊断服务和 2538 个子服务。未来还需要对更多不同车型和制造商的车辆进行评估。

为了在提取车辆数据时实现更大范围的覆盖，我们为该端口扫描工具新增了自动协议检测功能。

3.2 自动协议检测

要实现端口扫描工具的自动化运行，需要了解所使用的传输协议和 CAN 标识符类型，但默认情况下，这些信息是未知的。因此，我们决定开发自动协议检测功能，以扩展端口扫描工具的功能。

首先，需要区分 11 位和 29 位 CAN 总线系统。11 位 CAN 系统被称为 CAN 2.0A，而 29 位 CAN 系统被称为 CAN 2.0B。这两种格式均在文献中进行了规定。可以通过 CAN 消息控制字段中的标识符扩展（IDE）位来区分这两种格式。基于此，该工具会监控 CAN 总线，并检查 IDE 位是显性（值为 0）还是隐性（值为 1）。显性位表示使用标准的 11 位格式。

确定标识符格式后，就可以识别传输协议和诊断协议了。如第二部分所述，相关的诊断协议（UDS、OBD、KWP 2000）都遵循图 1 所示的相同方案，它们之间的主要区别在于所调用的服务不同，这导致可调用的服务标识符（SID）范围存在差异。因此，要识别受支持的诊断协议，需要向车辆电子控制单元（ECU）发送请求，以调用可能的服务标识符（SID）。如果某个服务标识符（SID）收到了响应，则表明对应的服务及其相关诊断协议是受支持的。

由于诊断协议嵌入在传输协议格式中，因此可以同时对这些协议进行识别。为了识别传输协议，我们扩展了端口扫描工具的穷举搜索功能。该方法首先将嵌入在各种可能传输协议（ISOTP、TP 2.0、SAE J1939）中的诊断请求发送出去。如果其中某种组合收到了响应（无论是肯定响应还是否定响应），则表明对应的传输协议是受支持的。

图3、11位CAN ID的协议检测程序

图 3 展示了针对 11 位 CAN 标识符的这一识别过程。如果 CAN 标识符在 0x7E0 到 0x7EF 的范围内，则表明涉及车载诊断（OBD），因为该范围是为结合了国际标准化组织传输协议（ISOTP）的这种诊断协议预留的。如果 CAN 标识符不在该范围内，则需要通过检查 CAN 帧是否符合国际标准化组织传输协议（ISOTP）和传输协议（TP）2.0 的格式，来确定所使用的传输协议。识别出传输协议后，再检查是否支持统一诊断服务（UDS）和关键字协议（KWP）2000 这两种诊断协议。识别出诊断协议后，就可以评估下一个 CAN 标识符对应的 CAN 帧，直到检查完所有标识符。

需要说明的是，一个通信系统中可能会使用多种传输协议。例如，即使 CAN 使用了国际标准化组织传输协议（ISOTP），它也可能同时使用传输协议（TP）2.0。诊断协议的使用情况也是如此。为了使过程说明更加清晰，图 3 中并未体现这种可能性。

根据 CAN 标识符，可以减少可能的协议组合数量。例如，由于 SAE J1939 仅定义用于 29 位系统，因此在 11 位 CAN 系统中无需考虑该协议。对于 29 位 CAN 标识符，也可以采用类似的方式减少协议组合的数量。从理论上讲，这些系统有2^29个可能的标识符，因此在实际操作中，对 29 位标识符进行穷举搜索是不可行的。为了解决这一问题，我们采用了诊断协议的相关规范。在诊断过程中，29 位 CAN 标识符具有规定的结构。图 4 展示了 ISO 15765 中规定的标识符结构。如图所示，该结构区分了源地址和目标地址。源地址是测试人员（端口扫描工具）的地址，通常设置为 0xF1。目标地址是电子控制单元（ECU）的地址。由于目标地址仅由 11 位构成，因此可能的标识符数量减少到了2^11个，这与 CAN 2.0A 11 位标识符的数量相同。SAE J1939 协议也具有类似的结构，其目标地址仅由 8 位构成，因此可能的标识符数量仅为2^{8个。这两项规范使得原本可能存在的2}29个 CAN 标识符数量大幅减少。

图4、ISO 15765中的29位CAN标识符

3.3 示例

为了说明协议检测的工作原理，我们以 11 位 CAN 系统为例来描述其功能，具体情况如表 1 所示。该示例遵循图 3 所示的控制流程，并分为三个步骤进行说明。在示例的第一个步骤（表 1 中的第 1 行）中，将介绍国际标准化组织传输协议（ISOTP）与车载诊断（OBD）结合使用时的协议检测过程。第二个步骤（表 1 中的第 2 行）将介绍国际标准化组织传输协议（ISOTP）与统一诊断服务（UDS）结合使用时的协议检测过程。最后一个步骤（表 1 中的第 3 行）将介绍国际标准化组织传输协议（ISOTP）与关键字协议（KWP）2000 结合使用时的协议检测过程。

为简洁起见，我们决定不在示例中展示传输协议（TP）2.0 或涉及消息分段（数据字节超过 8 个）的国际标准化组织传输协议（ISOTP）的协议检测过程，因为这些传输协议的结构更为复杂，超出了本文的讨论范围。

表 1、按照图 3 所述，通过发送不同请求实现自动协议检测的示例（数值采用十六进制格式）

在第一个步骤（第 1 行）中，基于国际标准化组织传输协议（ISOTP）和车载诊断（OBD）的诊断请求被发送到 CAN 总线上。由于该请求收到了响应，并且 CAN 标识符在 0x7E0 到 0x7EF 的范围内，因此可以确定传输协议为国际标准化组织传输协议（ISOTP），诊断协议为车载诊断（OBD）。

第二个步骤（第 2 行）与第一个步骤类似，不同之处在于请求所使用的诊断协议变为了统一诊断服务（UDS）。响应的 CAN 标识符不在车载诊断（OBD）的标识符范围内，因此根据图 3 的流程，需要检查该响应是否符合国际标准化组织传输协议（ISOTP）的格式。由于该响应符合该传输协议的格式，因此可以确定支持该传输协议。之后，需要进一步识别诊断协议。所请求的服务（服务标识符（SID）=0x10）及其子服务（0x03）是统一诊断服务（UDS）特有的服务，因此可以确定诊断协议为统一诊断服务（UDS）。

最后一个步骤（第 3 行）涉及基于国际标准化组织传输协议（ISOTP）和关键字协议（KWP）2000 的诊断请求。其检测过程与前两个步骤类似。由于所请求的服务（服务标识符（SID）=0x1A）是关键字协议（KWP）2000 特有的服务，因此可以确定诊断协议为关键字协议（KWP）2000。

需要说明的是，上述传输协议和诊断协议相对复杂，因此表 1 中的示例以及图 3 中的检测流程在某些协议组合或检测功能方面可能会有所不同。例如，统一诊断服务（UDS）是关键字协议（KWP）2000 的替代协议，并且这两种协议的许多服务具有相同的服务标识符（SID），因此在这种情况下，需要在子服务层面对它们进行区分。

另一个可能存在差异的方面与物理层面相关，即总线系统的波特率。例如，与车载诊断（OBD）不同，统一诊断服务（UDS）并未规定波特率。我们不想过多深入讨论这些特殊的协议属性，而是希望将重点放在自动协议检测能够为渗透测试实现的用例上，这将在接下来的部分中进行介绍。

4、用例

在本节中，我们将介绍端口扫描工具及其自动协议检测功能在渗透测试中的用例。

4.1 收集电子控制单元（ECU）、服务、子服务和车辆数据

前文已经介绍了提取电子控制单元（ECU）、其诊断服务和子服务相关信息的功能，该功能是端口扫描工具的一部分。此外，该工具还具备提取车辆数据的功能，例如故障存储器数据、底盘编号或电子控制单元（ECU）固件版本等，这些数据可以通过请求诊断服务来获取。

此外，新增的自动协议检测功能使该工具能够收集更多的车辆信息，包括规定的诊断功能和制造商特定的诊断功能，从而实现更大范围的覆盖。这对于渗透测试来说是一个优势，因为它使测试人员能够获取更多关于车辆的信息，这在黑盒渗透测试中尤为重要。

4.2 路由表逆向工程

通常，诊断测试设备会连接到车辆的车载诊断（OBD）接口。对于通常具有多个总线系统的车辆，这些总线系统通过网关相互隔离，每个网关负责将一个总线系统的消息格式转换为另一个总线系统的消息格式（例如，将 CAN 消息格式转换为 LIN 消息格式）。如果向需要通过多个网关和总线系统才能连接到车载诊断（OBD）接口的控制单元发送诊断请求，那么诊断消息必须通过这些连接路由到目标电子控制单元（ECU）。

这种路由方式在车辆开发过程中以路由表的形式确定，而测试人员并不了解该路由表。从渗透测试的角度来看，通过自动协议检测功能可以实现对该路由表的逆向工程：发送诊断请求，并观察车载诊断（OBD）接口、网关和目标电子控制单元（ECU）之间总线系统上的消息路由情况。但需要说明的是，这需要与这些总线系统建立物理连接。

4.3 自动生成测试用例

基于识别到的车辆网络协议，可以自动生成测试用例。这可以基于已知的漏洞来实现，这些漏洞可用于利用过去曾受到攻击的诊断服务。第一部分中提到的许多攻击都是基于对诊断服务的利用。因此，这些信息可以作为自动生成测试用例的数据输入。

另一个可能的数据输入来源是我们自己收集的车辆漏洞和攻击信息，这些信息已按照分类法进行分类，可用于支持渗透测试。

4.4 模糊测试

在模糊测试中，会通过输入随机或经过修改的数据来测试系统的容错性或稳健性，这种方法能够发现系统中的新漏洞。文献展示了模糊测试技术在汽车领域的应用，即在该文献中，使用 CAN 消息的数据字节进行模糊测试；文献则介绍了如何对模糊测试工具 beSTORM 进行扩展，以支持控制器局域网灵活数据速率（CAN FD）协议。

汽车行业中另一个常用的模糊测试工具是 CaringCaribou，该工具是在 “通过修复漏洞增强软件安全性和安全性（HEAVENS）” 研究项目中开发的。

了解传输协议和诊断协议后，可以根据这些协议的相关信息确定模糊测试的输入序列，具体方法是在这些协议的范围内对数据进行修改。

4.5 漏洞扫描

另一个用例涉及漏洞扫描，即扫描系统以查找已知的安全漏洞。通过自动检测受支持的车辆网络协议，可以实现扫描过程的自动化。漏洞数据库可以作为我们工具的数据输入来源。卡尔斯鲁厄应用科学大学（Karlsruhe University of Applied Sciences）目前正致力于在 “互联自动驾驶汽车安全（SecForCARs）”项目中为汽车领域开发这样一个漏洞数据库。

4.6 利用工具

考虑到上述功能，我们的工具可以扩展为一种利用工具，利用该工具可以对发现的漏洞进行利用，从而对车辆发起实际攻击。因此，该工具可以为渗透测试过程提供积极支持，并实现该过程的部分自动化。

5、结论与未来工作

在本文中，我们介绍了对汽车端口扫描工具的扩展，即为该工具新增了车辆网络协议自动检测功能。自动协议检测功能催生了新的用例，这些用例通过新增功能扩展了渗透测试活动的范围。这尤其为黑盒渗透测试提供了支持，并实现了该过程的部分自动化。

目前，仅实现了 “收集电子控制单元（ECU）、服务、子服务和车辆数据” 以及 “路由表逆向工程” 这两个用例，因此未来的工作可以包括为该工具扩展更多的用例。

为了将上述用例付诸实践，需要在该工具中集成更多的总线系统，例如 LIN、以太网、CAN FD 和 FlexRay。这些总线系统部分使用不同的协议，例如以太网传输层使用的用户数据报协议（UDP）和传输控制协议（TCP），以及以太网应用层使用的基于互联网协议的诊断（DoIP）协议。因此，可以考虑为该工具扩展这些协议。

由于已经发生了多起针对车辆的远程攻击，因此未来的另一项扩展工作可以是在该工具中集成无线技术，以便评估此类攻击的风险。通过这种方式，可以将该端口扫描工具扩展为一款实用的车辆网络渗透测试工具。

这两年，IT行业面临经济周期波动与AI产业结构调整的双重压力，确实有很多运维与网络工程师因企业缩编或技术迭代而暂时失业。

很多人都在提运维网工失业后就只能去跑滴滴送外卖了，但我想分享的是，对于运维人员来说，即便失业以后仍然有很多副业可以尝试。

网工/运维/测试副业方向

运维网工，千万不要再错过这些副业机会！

第一个是知识付费类副业：输出经验打造个人IP

在线教育平台讲师

操作路径：在慕课网、极客时间等平台开设《CCNA实战》《Linux运维从入门到精通》等课程，或与培训机构合作录制专题课。
收益模式：课程销售分成、企业内训。

技术博客与公众号运营

操作路径：撰写网络协议解析、故障排查案例、设备评测等深度文章，通过公众号广告、付费专栏及企业合作变现。
收益关键：每周更新2-3篇原创，结合SEO优化与社群运营。

第二个是技术类副业：深耕专业领域变现

企业网络设备配置与优化服务

操作路径：为中小型企业提供路由器、交换机、防火墙等设备的配置调试、性能优化及故障排查服务。可通过本地IT服务公司合作或自建线上接单平台获客。
收益模式：按项目收费或签订年度维护合同。

远程IT基础设施代维

操作路径：通过承接服务器监控、日志分析、备份恢复等远程代维任务。适合熟悉Zabbix、ELK等技术栈的工程师。
收益模式：按工时计费或包月服务。

网络安全顾问与渗透测试

操作路径：利用OWASP Top 10漏洞分析、Nmap/BurpSuite等工具，为企业提供漏洞扫描、渗透测试及安全加固方案。需考取CISP等认证提升资质。
收益模式：单次渗透测试报告收费；长期安全顾问年费。

比如不久前跟我一起聊天的一个粉丝，他自己之前是大四实习的时候做的运维，发现运维7*24小时待命受不了，就准备转网安，学了差不多2个月，然后开始挖漏洞，光是补天的漏洞奖励也有个四五千，他说自己每个月的房租和饭钱就够了。

为什么我会推荐你网安是运维和网工测试人员的绝佳副业&转型方向?

1.你的经验是巨大优势: 你比任何人都懂系统、网络和架构。漏洞挖掘、内网渗透、应急响应，这些核心安全能力本质上是“攻击视角下的运维”。你的运维背景不是从零开始，而是降维打击。

2.越老越吃香，规避年龄危机: 安全行业极度依赖经验。你的排查思路、风险意识和对复杂系统的理解能力，会随着项目积累而愈发珍贵，真正做到“姜还是老的辣”。

3.职业选择极其灵活: 你可以加入企业成为安全专家，可以兼职“挖洞“获取丰厚奖金，甚至可以成为自由顾问。这种多样性为你提供了前所未有的抗风险能力。

4.市场需求爆发，前景广阔: 在国家级政策的推动下，从一线城市到二三线地区，安全人才缺口正在急剧扩大。现在布局，正是抢占未来先机的黄金时刻。

网工运维测试转行学习网络安全路线

在这里插入图片描述

（一）第一阶段：网络安全筑基

1. 阶段目标

你已经有运维经验了，所以操作系统、网络协议这些你不是零基础。但要学安全，得重新过一遍——只不过这次我们是带着“安全视角”去学。

2. 学习内容

**操作系统强化：**你需要重点学习 Windows、Linux 操作系统安全配置，对比运维工作中常规配置与安全配置的差异，深化系统安全认知（比如说日志审计配置，为应急响应日志分析打基础）。

**网络协议深化：**结合过往网络协议应用经验，聚焦 TCP/IP 协议簇中的安全漏洞及防护机制，如 ARP 欺骗、TCP 三次握手漏洞等（为 SRC 漏扫中协议层漏洞识别铺垫）。

**Web 与数据库基础：**补充 Web 架构、HTTP 协议及 MySQL、SQL Server 等数据库安全相关知识，了解 Web 应用与数据库在网安中的作用。

**编程语言入门：**学习 Python 基础语法，掌握简单脚本编写，为后续 SRC 漏扫自动化脚本开发及应急响应工具使用打基础。

**工具实战：**集中训练抓包工具（Wireshark）、渗透测试工具（Nmap）、漏洞扫描工具（Nessus 基础版）的使用，结合模拟场景练习工具应用（掌握基础扫描逻辑，为 SRC 漏扫工具进阶做准备）。

（二）第二阶段：漏洞挖掘与 SRC 漏扫实战

1. 阶段目标

这阶段是真正开始“动手”了。信息收集、漏洞分析、工具联动，一样不能少。

熟练运用漏洞挖掘及 SRC 漏扫工具，具备独立挖掘常见漏洞及 SRC 平台漏扫实战能力，尝试通过 SRC 挖洞搞钱，不管是低危漏洞还是高危漏洞，先挖到一个。

2. 学习内容

信息收集实战：结合运维中对网络拓扑、设备信息的了解，强化基本信息收集、网络空间搜索引擎（Shodan、ZoomEye）、域名及端口信息收集技巧，针对企业级网络场景开展信息收集练习（为 SRC 漏扫目标筛选提供支撑）。

漏洞原理与分析：深入学习 SQL 注入、CSRF、文件上传等常见漏洞的原理、危害及利用方法，结合运维工作中遇到的类似问题进行关联分析（明确 SRC 漏扫重点漏洞类型）。

工具进阶与 SRC 漏扫应用：

系统学习 SQLMap、BurpSuite、AWVS 等工具的高级功能，开展工具联用实战训练；
专项学习 SRC 漏扫流程：包括 SRC 平台规则解读（如漏洞提交规范、奖励机制）、漏扫目标范围界定、漏扫策略制定（全量扫描 vs 定向扫描）、漏扫结果验证与复现；
实战训练：使用 AWVS+BurpSuite 组合开展 SRC 平台目标漏扫，练习 “扫描 - 验证 - 漏洞报告撰写 - 平台提交” 全流程。
SRC 实战演练：选择合适的 SRC 平台（如补天、CNVD）进行漏洞挖掘与漏扫实战，积累实战经验，尝试获取挖洞收益。

恭喜你，如果学到这里，你基本可以下班搞搞副业创收了，并且具备渗透测试工程师必备的「渗透技巧」、「溯源能力」，让你在黑客盛行的年代别背锅，工作实现升职加薪的同时也能开创副业创收！

如果你想要入坑黑客&网络安全，笔者给大家准备了一份：全网最全的网络安全资料包需要保存下方图片，微信扫码即可前往获取!

因篇幅有限，仅展示部分资料，需要点击下方链接即可前往获取

优快云大礼包：《黑客&网络安全入门&进阶学习资源包》免费分享

（三）第三阶段：渗透测试技能学习

1. 阶段目标

全面掌握渗透测试理论与实战技能，能够独立完成渗透测试项目，编写规范的渗透测试报告，具备渗透测试工程师岗位能力，为护网红蓝对抗及应急响应提供技术支撑。

2. 学习内容

渗透测试核心理论：系统学习渗透测试流程、方法论及法律法规知识，明确渗透测试边界与规范（与红蓝对抗攻击边界要求一致）。

实战技能训练：开展漏洞扫描、漏洞利用、电商系统渗透测试、内网渗透、权限提升（Windows、Linux）、代码审计等实战训练，结合运维中熟悉的系统环境设计测试场景（强化红蓝对抗攻击端技术能力）。

工具开发实践：基于 Python 编程基础，学习渗透测试工具开发技巧，开发简单的自动化测试脚本（可拓展用于 SRC 漏扫自动化及应急响应辅助工具）。

报告编写指导：学习渗透测试报告的结构与编写规范，完成多个不同场景的渗透测试报告撰写练习（与 SRC 漏洞报告、应急响应报告撰写逻辑互通）。

（四）第四阶段：企业级安全攻防（含红蓝对抗）、应急响应

1. 阶段目标

掌握企业级安全攻防、护网红蓝对抗及应急响应核心技能，考取网安行业相关证书。

2. 学习内容

护网红蓝对抗专项：

红蓝对抗基础：学习护网行动背景、红蓝对抗规则（攻击范围、禁止行为）、红蓝双方角色职责（红队：模拟攻击；蓝队：防御检测与应急处置）；
红队实战技能：强化内网渗透、横向移动、权限维持、免杀攻击等高级技巧，模拟护网中常见攻击场景；
蓝队实战技能：学习安全设备（防火墙、IDS/IPS、WAF）联动防御配置、安全监控平台（SOC）使用、攻击行为研判与溯源方法；
模拟护网演练：参与团队式红蓝对抗演练，完整体验 “攻击 - 检测 - 防御 - 处置” 全流程。
应急响应专项：
应急响应流程：学习应急响应 6 步流程（准备 - 检测 - 遏制 - 根除 - 恢复 - 总结），掌握各环节核心任务；
实战技能：开展操作系统入侵响应（如病毒木马清除、异常进程终止）、数据泄露应急处置、漏洞应急修补等实战训练；
工具应用：学习应急响应工具（如 Autoruns、Process Monitor、病毒分析工具）的使用，提升处置效率；
案例复盘：分析真实网络安全事件应急响应案例（如勒索病毒事件），总结处置经验。
其他企业级攻防技能：学习社工与钓鱼、CTF 夺旗赛解析等内容，结合运维中企业安全防护需求深化理解。