Vulnerability scanning system and method based on LLDP extension

Abstract

The invention provides a vulnerability scanning system and method based on LLDP extension, and relates to the field of network security protection. The system comprises an equipment end and a scanning end, the method comprises the following steps: generating an extended LLDP message containing a custom equipment asset attribute TLV, a topological structure TLV, a vulnerability association TLV and a risk rating TLV by an equipment end, and periodically sending the extended LLDP message; the scanning end is used for monitoring an extended LLDP message in a network and analyzing an extended TLV field in the extended LLDP message; asset identification is carried out based on the analyzed asset attribute TLV, and equipment information is stored in an equipment information base; planning a scanning path according to the topological structure TLV, and re-planning the path when the dynamic topological change is detected; in a vulnerability detection process, vulnerability related equipment connection information is recorded by utilizing a vulnerability association TLV, a risk rating is calculated and updated to a risk rating TLV through a risk evaluation module in combination with asset attributes and vulnerability severity, and meanwhile, sensitive information is generated into a digital signature TLV.

Description

Technical Field

[0001] This invention relates to the field of network security protection, and in particular to a vulnerability scanning system and method based on LLDP extensions. Background Technology

[0002] In the current network security protection system, traditional vulnerability scanning technologies face numerous challenges. Taking host-based vulnerability scanning as an example, in proxy server mode, the proxy software is limited by specific operating systems and has poor compatibility; while agentless mode can scan more networked systems, it relies on stable network connections, resulting in insufficient comprehensiveness of assessment; stand-alone scanning is not only time-consuming but also extremely impractical when managing a large number of endpoints. Network scanning often uses techniques such as port scanning and network mapping to detect vulnerabilities, but it relies excessively on predefined rule bases. Furthermore, in terms of asset identification, existing scanning technologies struggle to accurately obtain key information such as the business system to which a device belongs and the asset's importance level, resulting in incomplete asset profiles. At the same time, facing dynamic changes in network topology, such as changes in link bandwidth and latency, as well as the addition or removal of devices, traditional scanning path planning cannot be adjusted in real time, severely impacting scanning efficiency and coverage. Summary of the Invention

[0003] Purpose of the invention: To address the problems of traditional vulnerability scanning, such as increased network load due to active probing, inaccurate asset identification, and low efficiency due to scanning path planning not adapting to topology characteristics, this invention proposes a vulnerability scanning system and method based on LLDP extensions. By passively receiving LLDP messages containing extended fields, network interference is reduced, asset identification accuracy and scanning efficiency are improved, and vulnerability detection and risk assessment effects are optimized.

[0004] In a first aspect, the present invention provides a vulnerability scanning system based on LLDP extensions, comprising a device end and a scanning end; The device is configured with the LLDP protocol to generate an extended LLDP message containing a custom extended TLV, and transmits the extended LLDP message through a preset transmission strategy. The custom extended TLV includes at least an asset attribute TLV, a topology TLV, a vulnerability association TLV, and a risk rating TLV. The preset transmission strategy includes at least a periodic transmission mechanism, or a transmission mechanism that combines periodic transmission with event triggering. The scanning terminal performs vulnerability scanning functions by listening to LLDP packets in the network without actively sending probe packets. The scanning terminal includes at least an LLDP packet capture module, an extended TLV parsing module, a device information database, a path planning module, a vulnerability matching engine, and a risk assessment module. The LLDP packet capture module receives or monitors LLDP traffic in the network, filters and extracts packets containing the custom extended TLV. The extended TLV parsing module parses the message according to the LLDP protocol format, separates the standard TLV from the custom extended TLV, parses the "value field" of the custom extended TLV, and extracts the device-related structured data. The device information database stores the device information parsed by the extended TLV parsing module, and ensures the validity of the information through a preset deduplication rule. At the same time, the information is updated based on the message sending cycle of the device. The path planning module calculates the scanning path from the scanning source to the target device using a path planning algorithm based on the topology-related information in the topology TLV. The vulnerability matching engine connects to a vulnerability database and determines whether a device has vulnerability risks through preset matching rules. The risk assessment module combines the key asset information in the asset attribute TLV, the risk score information of the vulnerability, and the device association information in the vulnerability association TLV to obtain a risk rating result according to a preset risk rating algorithm.

[0005] In a further embodiment of the first aspect, in the preset transmission strategy of the device, the periodic transmission mechanism is that the device sends a message containing a complete custom extended TLV every 30 seconds; the event triggering mechanism is that when an asset attribute change or topology change event occurs, the extended LLDP message is immediately triggered to be sent. The LLDP packet capture module listens for Layer 2 LLDP traffic, and its destination MAC is the standard LLDP multicast address 01:80:c2:00:00:0e.

[0006] In a further embodiment of the first aspect, the custom extension TLV uses type value 127 (0x7F) and contains 3 bytes of OUI to identify the extension source; the "value field" of the custom extension TLV has a length of no more than 1500 bytes; The custom extended TLV also includes a digital signature TLV and an ACK TLV; The digital signature TLV is used to sign and encrypt the key data of the extended TLV to ensure the security of data transmission; the ACK TLV is used to provide feedback on the reception and parsing status of the extended LLDP message.

[0007] In a further embodiment of the first aspect, the asset attribute TLV includes at least one or more of the following: the business system to which the device belongs, the asset importance level, the device type, the running application information, the device identification information, the operating system information, the opened service ports and protocol information, and the device patch update status. The topology TLV includes at least one or more of the following: network link bandwidth, latency, dynamic topology change information, and link utilization. The vulnerability-associated TLV must include at least one or more of the following: device identifier, device type, connection interface information, connection type, and communication protocol. The risk rating TLV includes at least one or more of the following: asset value factor, attack path complexity factor, vulnerability threat factor, and impact of associated devices.

[0008] In a further embodiment of the first aspect, in the asset attribute TLV, the asset importance level is a fixed-length field of 1 byte, and the higher the value, the higher the importance; the device type is a 1-byte enumeration value used to represent servers, switches, firewalls, terminals, and IoT devices; the device patch update status adopts a bitmap form, with each bit corresponding to a known patch number, 1 indicating that it is installed and 0 indicating that it is not installed, and the bitmap length is dynamically adjusted according to the number of common patches; In the TLV topology, network link bandwidth is measured in Mbps and represented by a 4-byte unsigned integer; latency is measured in microseconds and stored as an 8-byte floating-point number; link utilization is a 4-byte unsigned integer, expressed as a percentage, ranging from 0 to 100; in the dynamic topology change information, when a device comes online, it carries basic device information; when a device goes offline, it records the device identifier and offline timestamp; when a link fails, it records the device interface identifier associated with the failed link and the time of the failure. The timestamp uses the Unix timestamp format and is stored as an 8-byte unsigned integer.

[0009] In a further embodiment of the first aspect, in the vulnerability-associated TLV, the device identifier is a globally unique device identifier UUIDv4, which is a 16-bit byte array; the connection interface information is a variable string with a maximum length of 32; the connection type is a 1-byte enumeration value, where 0x01 represents the upstream device, 0x02 represents the downstream device, and 0x03 represents the peer device; the communication protocol is a 4-byte bitmap, where each bit represents a protocol, TCP=1, UDP=2, ICMP=4, and HTTP=8. In the risk rating TLV, the asset value factor is a 4-byte floating-point number, calculated based on the business system, importance level, and data sensitivity in the asset attribute TLV; the attack path complexity is a 4-byte floating-point number, calculated as the reciprocal of the average attack hops based on the topology TLV; the vulnerability threat factor is a 4-byte floating-point number, calculated as CVSS score × exploit maturity factor, where exploit maturity factor is the number of publicly disclosed exploits / 10; and the impact of associated devices is a 4-byte floating-point number, calculated as the sum of the criticality of upstream and downstream devices based on the vulnerability association TLV.

[0010] In a further embodiment of the first aspect, in the digital signature TLV, the device uses a private key to sign the hash values ​​of all extended TLVs, and the scanning end verifies the validity of the signature through a pre-set list of device public keys; the hash value is generated using the SHA-256 algorithm; sensitive information is encrypted using the AES-128 algorithm, and the encryption key is generated through inter-device pre-shared key (PSK) negotiation; the encrypted field is stored in the TLV in the form of "encryption flag + ciphertext", the encryption flag is 1 byte, 0 represents plaintext, and 1 represents encryption; The ACK TLV response includes a sequence number, a parsing result status code, and a timestamp. The sequence number is an 8-byte unsigned integer, corresponding to the sequence number of the original message, used for message matching. The parsing result status code is a 1-word enumeration value, where 0 indicates success, 1 indicates partial error, 2 indicates format error, 3 indicates authentication failure, and 4 indicates timeout. The timestamp is an 8-byte unsigned integer, which is the Unix timestamp generated by the ACK, accurate to the microsecond.

[0011] In a further embodiment of the first aspect, the preset deduplication rule of the device information database is to deduplicat based on "device ID + timestamp"; The path planning module uses Dijkstra's algorithm; the topology-related information in the topology TLV includes link bandwidth and delay information. The vulnerability matching engine connects to a CVE database, an NVD public vulnerability database, or a private vulnerability database; the preset matching rules are "version matching" and "patch status comparison"; The vulnerability risk scoring information used in the risk assessment module is the CVSS score; the asset key information in the asset attribute TLV is the asset importance level; and the device association information in the vulnerability association TLV is the criticality information of upstream and downstream devices.

[0012] In a further embodiment of the first aspect, after receiving the extended LLDP message, the scanning end generates an acknowledgment message containing verification information and uses the ACK TLV response to feedback the reception status; if no acknowledgment is received for three consecutive times, the device shortens the sending interval to 5 seconds until it confirms that the scanning end has successfully received the message. When multiple devices send extended LLDP messages simultaneously, causing a conflict, a "priority + random backoff" strategy is adopted. The device priority is determined by the asset importance level, with devices at level 10 having the highest priority. If the priorities are the same, a random backoff time of 0-100ms is generated based on the last 4 bits of the MAC address.

[0013] A second aspect of the present invention provides a vulnerability scanning method based on LLDP extensions, which is applied to the vulnerability scanning system based on LLDP extensions described in the first aspect. The vulnerability scanning method includes the following steps: S1. Asset Identification Phase: After the vulnerability scanner starts, it listens for LLDP packets in the network and parses the custom extended TLV fields; it extracts the device asset information from the asset attribute TLV, stores it in the device information database, and establishes a mapping relationship between device identifiers and asset attributes; at the same time, it connects to the vulnerability database through the vulnerability matching engine to determine whether the device has vulnerability risks. If so, it marks the device risk level and prioritizes scanning tasks. S2, Scan Path Planning Stage: Based on the topology-related information in the topology TLV, the path planning algorithm is used to calculate the scan path from the scan source to each target device; if a topology change event is detected, the scan path is recalculated. S3. Vulnerability Detection and Risk Assessment Phase: During vulnerability detection, the connection relationship between vulnerable devices and associated devices is recorded in the vulnerability association TLV; the risk assessment module combines the information in the asset attribute TLV, topology TLV, and vulnerability association TLV to calculate the risk value of the device according to the preset risk rating algorithm; when the vulnerability status of the associated device changes, the risk recalculation of the current device is triggered.

[0014] In a further embodiment of the second aspect, in step S1, the device information database deduplicates the device asset information according to "device ID + timestamp" and updates the information in real time based on the message sending cycle of the device every 30 seconds; the vulnerability matching engine judges the device risk by "version matching" and "patch status comparison", that is, if the device software version has a known vulnerability and the corresponding patch is not installed, it is marked as high risk.

[0015] In a further embodiment of the second aspect, in step S2, the topology-related information in the topology structure TLV includes link bandwidth, latency, and link utilization; the path planning algorithm is the Dijkstra algorithm; the topology change events include device online, device offline, and link failure. When a device goes online, it carries a device identifier and an interface identifier. When a device goes offline, it records the device identifier and the offline timestamp. When a link failure occurs, it records the interface identifiers of the devices at both ends of the faulty link and the fault time.

[0016] In a further embodiment of the second aspect, in step S3, the risk value formula calculated by the preset risk rating algorithm is: Risk value = [(Asset value factor × 0.4) + (Vulnerability threat factor × 0.4) + (Impact of associated devices × 0.2)] × Attack path complexity; Among them, the asset value factor is calculated based on the business system, asset importance level, and data sensitivity in the asset attribute TLV; the vulnerability threat factor is CVSS score × exploit maturity factor, and the exploit maturity factor is the number of public EXPs / 10; the impact of associated devices is calculated based on the sum of the criticality of upstream and downstream devices in the vulnerability association TLV; and the attack path complexity is the reciprocal of the average attack hops calculated based on the topology TLV. Changes in the vulnerability status of associated devices include vulnerability patching and the addition of new vulnerabilities; when a vulnerability is patched on a downstream device, the associated risk factor of the current device decreases.

[0017] In a further embodiment of the second aspect, the method further includes an LLDP extended message interaction step: The device uses a strategy that combines periodic sending with event triggering to send extended LLDP messages. Under normal conditions, a complete message is sent every 30 seconds, and a message is sent immediately when asset attributes change or topology changes. After receiving a message, the scanner returns the status via an ACK TLV response. If no response is received three times in a row, the device will shorten the sending interval to 5 seconds. When multiple devices have conflicting messages, priority is determined according to the asset importance level. If the priorities are the same, a random backoff time of 0-100ms is generated based on the last 4 bits of the MAC address, and messages from higher priority devices are transmitted first.

[0018] Beneficial Effects: This invention shifts from "active probing" to "passive reception," reducing network interference. Information can be passively collected by listening to LLDP messages (including extended fields), eliminating the need for active probing and significantly reducing network interference and the risk of detection. Simultaneously, the extended fields accurately transmit vulnerability-related information, allowing the scanner to accurately identify the business systems to which all devices belong, asset importance levels, and other information. Furthermore, it can accurately plan scanning paths based on the topology, avoiding low-bandwidth and high-latency links and shortening scanning time. This invention significantly improves the accuracy of asset identification, scanning efficiency, and assists in vulnerability detection and risk assessment. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the LLDP data structure in the embodiment.

[0020] Figure 2 This is a schematic diagram of the LLDPDU structure in the embodiment.

[0021] Figure 3 This is a schematic diagram of the TLV structure in the embodiment.

[0022] Figure 4 This is a schematic diagram of a custom extended TLV structure in an embodiment.

[0023] Figure 5 This is a schematic diagram of the ACK TLV structure in the embodiment.

[0024] Figure 6 This is a diagram showing the overall architecture of the vulnerability scanning system based on LLDP extensions in this embodiment.

[0025] Figure 7 This is a schematic diagram of the scanning process in the embodiment.

[0026] Figure 8 This is a schematic diagram of the protocol interaction process and state management mechanism in the embodiment. Detailed Implementation

[0027] In the following description, numerous specific details are set forth in order to provide a more thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention can be practiced without one or more of these details. In other instances, certain technical features well-known in the art have not been described in order to avoid obscuring the invention.

[0028] Before describing the embodiments, the technical terms that appear below will be explained.

[0029] LLDP: Link Layer Discovery Protocol LLDPPU: LLDP Data Unit, a data unit encapsulated in an LLDP message. TLV: The smallest unit that makes up an LLDPDU CVSS: Common Vulnerability Scoring System This embodiment discloses a vulnerability scanning system based on LLDP extension, which consists of two main parts: a network device and a vulnerability scanner.

[0030] At the network device end, an extended LLDP message containing a custom device asset attribute TLV, topology TLV, vulnerability association TLV, and risk rating TLV is generated and sent periodically. The device asset attribute TLV includes the business system to which the device belongs, the asset importance level, and information on the key applications running. The topology TLV includes network link bandwidth, latency, and dynamic topology change information.

[0031] The vulnerability scanner listens for extended LLDP packets in the network and parses the extended TLV fields within them. Based on the parsed asset attribute TLVs, it identifies assets and stores device information in a device information database. It plans scanning paths according to the topology TLVs and replans paths when dynamic topology changes are detected. During vulnerability detection, it uses vulnerability-associated TLVs to record connection information of vulnerability-related devices. Combining asset attributes and vulnerability severity, it calculates a risk rating through a risk assessment module and updates it to the risk rating TLV. Simultaneously, it generates digitally signed TLVs for sensitive information to ensure that critical data is not leaked during transmission.

[0032] The implementation process of the technical solution of the present invention will be described in detail below with reference to the accompanying drawings.

[0033] I. Introduction to the LLDP Protocol See Figure 1 and Figure 2 The LLDP protocol encapsulates the main capabilities, management address, device identifier, and interface identifier of a local device into LLDP messages and transmits them to neighboring nodes. An LLDPDU is a data unit encapsulated within an LLDP message. Before assembling an LLDPDU, the device first encapsulates its local information into a TLV (Type-Length-Value) format, and then combines several TLVs into an LLDPDU, which is then encapsulated in the data portion of the LLDP message for transmission. Users can combine various different TLVs into an LLDPDU as needed. The device uses these different TLVs to announce its own status information and learn the status information of neighboring nodes.

[0034] See Figure 3 TLV contains the following parts: TLV Type represents the type of the TLV, and it occupies 7 bits. Each TLV has a different type value.

[0035] The TLV information string length represents the length of the TLV content, which occupies 9 bits.

[0036] The TLV information string represents the content of the TLV, and the maximum supported length is 511 bytes.

[0037] II. LLDP Extended Field Design See Figure 4 Custom TLVs must use type value 127 (0x7F) and contain a 3-byte OUI (Organization Unique Identifier) ​​to identify the extended source.

[0038] (Note: There is a limit to the length of TLV value fields, usually no more than 1500 bytes per field. Information granularity needs to be controlled.) 1) Asset Attribute TLV Information Field Design To enable in-depth mining of asset information, the asset attribute TLV (in addition to the port, IP, hostname, etc. included in the standard TLV fields) is designed, and a field format combining fixed length and variable length is adopted.

[0039] The device asset attribute TLV includes the business system to which the device belongs, asset importance level (a 1-byte fixed-length field, with higher values ​​indicating higher importance), device type (e.g., server / switch / firewall / terminal / IoT device, which can be represented by a 1-byte enumeration value), information on running critical applications, device ID, operating system version, kernel version, installed application software and versions, opened service ports and protocols, and the device's most recent patch update status (in bitmap format, each bit corresponds to a known patch number, 1 indicates installed, 0 indicates not installed; the bitmap length can be dynamically adjusted based on the number of common patches, e.g., a 16-byte bitmap for 128 common patches for a specific operating system). This information is the core basis for vulnerability scanning (it needs to be matched against the CVE database to determine if vulnerabilities exist).

[0040] 2) Topology TLV information field design The topology TLV includes network link bandwidth, latency, dynamic topology change information, and link utilization.

[0041] Network link bandwidth information is in Mbps and is represented by a 4-byte unsigned integer, which can accurately record common network link bandwidths (such as 100Mbps, 1Gbps, 10Gbps, etc.).

[0042] The delay information is measured in microseconds and stored using 8-byte floating-point numbers to ensure high-precision recording of link delays, thus meeting the accuracy requirements of topology information for scanning path planning.

[0043] Current link utilization: (4-byte unsigned integer, percentage format, range 0-100, the higher the percentage, the higher the link utilization) Dynamic topology change awareness: When a device comes online, it carries basic device information (such as device ID, interface ID, etc.). Timestamps: When a device goes offline, only the device ID and the offline timestamp are recorded; when a link fails, the interface IDs of the devices at both ends of the failed link and the time of the failure are recorded. The timestamps use the Unix timestamp format and are stored as 8-byte unsigned integers to ensure the uniqueness and accuracy of time information, facilitating the scanner's rapid response to topology changes.

[0044] 3) Design of Vulnerability-Associated TLV Information Fields Once a scanner discovers a vulnerability in a device, it records the connection information between the vulnerable device A and the backend device B and the frontend device C through the LLDP extended field, and records this associated device information in the vulnerability association TLV.

[0045] Device ID: A 16-bit byte array, a globally unique device identifier (UUIDv4). Device type: 1-byte enumeration value (0x01=server, 0x02=switch, 0x03=firewall, 0x04=terminal, etc.) Connection interface ID: Variable string (maximum 32), such as "eth0", "Gi1 / 0 / 1" Connection type: 1-byte enumeration value (0x01 = upstream device, 0x02 = downstream device, 0x03 = peer device) Communication protocol: 4-byte bitmap (each bit represents a protocol: TCP=1, UDP=2, ICMP=4, HTTP=8, etc.) 4) Risk rating TLV information field design The risk rating result is obtained by combining the asset importance level, the vulnerability's CVSS score, and the criticality of upstream and downstream devices in the vulnerability's associated TLV, according to the preset risk rating algorithm.

[0046] Asset Value Factor: A 4-byte floating-point number calculated based on the business system, importance level, and data sensitivity within the asset's TLV. Attack path complexity: 4-byte floating-point number, the reciprocal of the average attack hop count calculated based on the topology TLV (the fewer the hops, the larger the value). Vulnerability Threat Factor: 4-byte floating-point number, CVSS score × Exploitation Maturity Factor (number of publicly disclosed exploits / 10) Impact on related devices: 4-byte floating-point number, the sum of the criticality of upstream and downstream devices calculated based on the vulnerability's associated TLV. 5) Digital Signature TLV Information Field Design The device uses its private key to sign the hash value (SHA-256 algorithm) of all extended TLVs, and the scanner verifies the validity of the signature using a pre-configured list of device public keys.

[0047] Sensitive information (such as asset importance level and vulnerability correlation) is encrypted using the AES-128 algorithm, and the encryption key is generated through inter-device pre-shared key (PSK) negotiation.

[0048] The encrypted field is stored in the TLV in the form of "encryption flag + ciphertext". The flag is 1 byte (0 indicates plaintext, 1 indicates encryption) to ensure that critical data is not leaked during transmission.

[0049] 6) Design of the ACK TLV information field See Figure 5 The ACK TLV contains the original message's sequence number, parsing result (such as "complete parsing" or "partial field error"), and timestamp.

[0050] Sequence Number: An 8-byte unsigned integer corresponding to the sequence number of the original message, used for message matching. Parsing result status code: 1-word enumeration value (0=success, 1=partial error, 2=format error, 3=authentication failure, 4=timeout) Timestamp: An 8-byte unsigned integer, a Unix timestamp generated by ACK (accurate to the microsecond). III. Overall Architecture Design See overall architecture Figure 6 .

[0051] 1. Device side Configure the LLDP protocol in devices (servers, switches, terminals, etc.) to actively send custom extended TLVs in addition to the standard TLVs, carrying the critical information required for vulnerability scanning.

[0052] 2. Scanning end The scanning end does not need to actively send probe packets; it achieves its function by listening to LLDP packets in the network. It includes the following sub-modules: 1) LLDP message capture module Receive or listen to Layer 2 LLDP traffic (destination MAC is 01:80:c2:00:00:0e, standard LLDP multicast address), filter and extract packets containing custom extended TLVs.

[0053] 2) Extended TLV parsing module The message is parsed according to the LLDP protocol format, separating the standard TLV and the custom extended TLV. The "value field" of the extended TLV is parsed to extract structured data such as device version, application information, and patch status.

[0054] 3) Equipment Information Database The parsed device information is stored and deduplicated by "device ID + timestamp" to ensure the timeliness of the information (based on the LLDP default 30-second sending cycle, it can be updated in real time). 4) Path planning module When planning the scanning path, the scanner uses Dijkstra's algorithm to calculate the optimal path from the scanning source to the target device based on the link bandwidth and delay information in the topology TLV.

[0055] 5) Vulnerability Matching Engine Connect to public vulnerability databases such as CVE and NVD (or private vulnerability databases), and determine risks through "version matching" and "patch status comparison": if the device reports "OpenSSL1.0.2k", matches CVE-2022-2068 (affecting this version), and the patch status is "not installed", then it is marked as high risk.

[0056] 6) Risk Assessment Module When calculating the risk rating, the risk assessment module combines the asset importance level, the vulnerability's CVSS score, and the criticality of upstream and downstream devices in the vulnerability's associated TLV, and obtains the risk rating result according to the preset risk rating algorithm.

[0057] Asset Value Factor: Calculated based on the business systems, importance level, and data sensitivity within the asset's TLV. It reflects the asset's overall value, including its business importance and data sensitivity. Attack path complexity: The reciprocal of the average number of attack hops calculated based on the topology TLV. It reflects the ease with which an attacker can reach the target asset. The simpler the path, the fewer the hops; conversely, the higher the value, the higher the probability of the risk being triggered.

[0058] Vulnerability Threat Factor: CVSS Score × Exploitation Maturity Factor (Number of Publicly Published EXPs / 10). Reflects the inherent threat of the vulnerability (CVSS score) and its potential for exploitation (exploitation maturity). Impact on Associated Devices: The sum of the criticality of upstream and downstream devices based on the vulnerability's associated TLV. This reflects the risk transmission effect of the vulnerability's associated upstream and downstream devices on the current asset.

[0059] Risk value = [(Asset value factor × 0.4) + (Vulnerability threat factor × 0.4) + (Impact of related devices × 0.2)] × Attack path complexity When the vulnerability status of an associated device changes (such as being patched or added), the scanner automatically triggers a risk recalculation for the current device (for example, after a vulnerability is patched on a downstream device, the associated risk coefficient of the current device decreases).

[0060] IV. Vulnerability Scanning Process and LLDP Extended Field Integration Mechanism 1) Asset Identification Stage After the vulnerability scanner starts, it first enters the asset identification phase. The scanner listens for LLDP packets in the network and parses the extended TLV fields. For asset attribute TLVs, the scanner extracts and stores information such as the business system to which the device belongs and the asset importance level into the device information database, establishing a mapping relationship between device IDs and asset attributes. If the scanner receives an asset attribute TLV in an LLDP packet, it associates this information with the device ID, providing a basis for subsequent scanning resource allocation.

[0061] For software version and patch status TLV, the scanner compares the extracted software version number with the known vulnerability database. If a device's software version is found to have a known vulnerability, and the patch status bitmap shows that the corresponding patch is not installed, the scanner marks the device as high-risk and prioritizes a detailed vulnerability scan task.

[0062] 2) Scanning Path Planning Stage Based on the link bandwidth, latency information, and link utilization provided by the topology TLV, the scanner uses path planning algorithms such as Dijkstra's algorithm to calculate the optimal scanning path from the scanning source to each target device.

[0063] When the scanner detects a topology change event carried by the Dynamic Topology Change Aware TLV, it immediately pauses the current scanning task (if it is in progress) and recalculates the scanning path.

[0064] 3) Vulnerability Detection and Risk Assessment Phase During vulnerability detection, once a scanner discovers a vulnerability in a device, it records the connection relationships between that device and its upstream and downstream devices in the vulnerability association TLV. The vulnerability association TLV can completely record the vulnerability propagation path in the network, providing a topological dimension basis for risk assessment.

[0065] The risk assessment module calculates the risk rating of a device based on information from the device asset attribute TLV, topology TLV, and vulnerability-related TLV.

[0066] V. Protocol Interaction Process and Status Management LLDP Extended Message Exchange Mechanism 1) Message sending strategy The device transmits extended LLDP messages using a combination of periodic sending and event triggering. Under normal conditions, the device sends a message containing the complete extended TLV every 30 seconds to ensure that the scanner obtains the latest information in real time. When events such as changes in asset attributes (e.g., software version updates) or topology changes (e.g., link failures) occur, message sending is triggered immediately to shorten the state synchronization delay.

[0067] 2) Scanner response mechanism After receiving the extended LLDP message, the scanner generates an acknowledgment message containing verification information and uses a custom ACK TLV to report the reception status. The ACK TLV includes the original message's sequence number, parsing result (such as "complete parsing" or "partial field error"), and timestamp, which the sending device uses to adjust its retransmission strategy. If no acknowledgment is received three consecutive times, the device shortens the transmission interval to 5 seconds until it confirms successful reception by the scanner.

[0068] 3) Conflict resolution mechanism When multiple devices simultaneously send extended LLDP messages, causing a collision, a "priority + random backoff" strategy is adopted. Device priority is determined by the asset importance level (equivalent to devices at level 10, which have the highest priority). If the priorities are the same, a random backoff time (0-100ms) is generated based on the last 4 bits of the MAC address to ensure that the status information of the more important devices is transmitted first.

[0069] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification. Although the present invention has been shown and described with reference to specific preferred embodiments, it should not be construed as limiting the invention itself. Various changes in form and detail may be made without departing from the spirit and scope of the invention as defined in the appended claims.

Claims

1. A vulnerability scanning system based on LLDP extensions, characterized in that, Including the device end and the scanning end; The device generates an extended LLDP message containing a custom device asset attribute TLV, topology TLV, vulnerability association TLV, and risk rating TLV, and sends it periodically; the device asset attribute TLV includes the business system to which the device belongs, the asset importance level, and information on the key applications running on it. The topology TLV contains information on network link bandwidth, latency, and dynamic topology changes; The scanning end is used to listen to the extended LLDP packets in the network, parse the extended TLV fields therein; identify assets based on the parsed asset attribute TLV, store the device information in the device information database; plan the scanning path according to the topology TLV, and replan the path when dynamic topology changes are detected; During the vulnerability detection process, the vulnerability association TLV is used to record the connection information of the vulnerable devices. Combined with the asset attributes and the severity of the vulnerability, the risk rating is calculated by the risk assessment module and updated to the risk rating TLV. At the same time, sensitive information is generated into a digital signature TLV.

2. The vulnerability scanning system based on LLDP extension according to claim 1, characterized in that, The device is configured with the LLDP protocol to generate an extended LLDP message containing a custom extended TLV, and transmits the extended LLDP message through a preset sending strategy; the custom extended TLV includes asset attribute TLV, topology TLV, vulnerability association TLV, and risk rating TLV. The preset sending strategy includes at least a periodic sending mechanism, or a sending mechanism that combines periodic sending with event triggering.

3. The vulnerability scanning system based on LLDP extension according to claim 1, characterized in that, The scanning terminal performs vulnerability scanning functions by listening to LLDP packets in the network without actively sending probe packets. The scanning terminal includes an LLDP packet capture module, an extended TLV parsing module, a device information database, a path planning module, a vulnerability matching engine, and a risk assessment module. The LLDP packet capture module receives or monitors LLDP traffic in the network, filters and extracts packets containing the custom extended TLV. The extended TLV parsing module parses the message according to the LLDP protocol format, separates the standard TLV from the custom extended TLV, parses the "value field" of the custom extended TLV, and extracts the device-related structured data. The device information database stores the device information parsed by the extended TLV parsing module, and ensures the validity of the information through a preset deduplication rule. At the same time, the information is updated based on the message sending cycle of the device. The path planning module calculates the scanning path from the scanning source to the target device using a path planning algorithm based on the topology-related information in the topology TLV. The vulnerability matching engine connects to a vulnerability database and determines whether a device has vulnerability risks through preset matching rules. The risk assessment module combines the key asset information in the asset attribute TLV, the risk score information of the vulnerability, and the device association information in the vulnerability association TLV to obtain a risk rating result according to a preset risk rating algorithm.

4. The vulnerability scanning system based on LLDP extension according to claim 1, characterized in that, In the preset sending strategy of the device, the periodic sending mechanism is that the device sends a message containing a complete custom extended TLV once every predetermined time interval. The event triggering mechanism is to immediately trigger the sending of extended LLDP messages when asset attribute changes or topology changes occur. The LLDP packet capture module listens for Layer 2 LLDP traffic, and its destination MAC is the standard LLDP multicast address 01:80:c2:00:00:0e.

5. A vulnerability scanning system based on LLDP extensions according to claim 1, characterized in that, The custom extension TLV uses the type value hexadecimal 0x7F and contains 3 bytes of OUI to identify the extension source; the "value field" of the custom extension TLV has a length of no more than 1500 bytes; The custom extended TLV also includes a digital signature TLV and an ACK TLV; The digital signature TLV is used to sign and encrypt the key data of the extended TLV to ensure the security of data transmission; the ACK TLV is used to provide feedback on the reception and parsing status of the extended LLDP message.

6. A vulnerability scanning system based on LLDP extensions according to claim 1, characterized in that, The asset attribute TLV shall include at least one or more of the following: the business system to which the device belongs, the asset importance level, the device type, the running application information, the device identification information, the operating system information, the opened service ports and protocol information, and the device patch update status. The topology TLV includes at least one or more of the following: network link bandwidth, latency, dynamic topology change information, and link utilization. The vulnerability-associated TLV must include at least one or more of the following: device identifier, device type, connection interface information, connection type, and communication protocol. The risk rating TLV includes at least one or more of the following: asset value factor, attack path complexity factor, vulnerability threat factor, and impact of associated devices.

7. A vulnerability scanning system based on LLDP extensions according to claim 6, characterized in that, In the asset attribute TLV, the asset importance level is a fixed-length field of 1 byte, with higher values ​​indicating higher importance; the device type is a 1-byte enumeration value used to represent servers, switches, firewalls, terminals, and IoT devices; the device patch update status is in bitmap form, with each bit corresponding to a known patch number, 1 indicating that it is installed and 0 indicating that it is not installed, and the bitmap length is dynamically adjusted according to the number of common patches; In the TLV topology, network link bandwidth is measured in Mbps and represented by a 4-byte unsigned integer; latency is measured in microseconds and stored as an 8-byte floating-point number; link utilization is a 4-byte unsigned integer, expressed as a percentage, ranging from 0 to 100; in the dynamic topology change information, when a device comes online, it carries basic device information; when a device goes offline, it records the device identifier and offline timestamp; when a link fails, it records the device interface identifier associated with the failed link and the time of the failure. The timestamp uses the Unix timestamp format and is stored as an 8-byte unsigned integer.

8. A vulnerability scanning system based on LLDP extensions according to claim 6, characterized in that, In the vulnerability-associated TLV, the device identifier is a globally unique device identifier UUIDv4, which is a 16-bit byte array; the connection interface information is a variable string with a maximum length of 32; the connection type is a 1-byte enumeration value, where 0x01 represents the upstream device, 0x02 represents the downstream device, and 0x03 represents the peer device. The communication protocol is a 4-byte bitmap, with each bit representing a protocol: TCP=1, UDP=2, ICMP=4, HTTP=8. In the risk rating TLV, the asset value factor is a 4-byte floating-point number, calculated based on the business system, importance level, and data sensitivity in the asset attribute TLV; the attack path complexity is a 4-byte floating-point number, calculated as the reciprocal of the average attack hops based on the topology TLV; the vulnerability threat factor is a 4-byte floating-point number, calculated as CVSS score × exploit maturity factor, where exploit maturity factor is the number of publicly disclosed exploits / 10; and the impact of associated devices is a 4-byte floating-point number, calculated as the sum of the criticality of upstream and downstream devices based on the vulnerability association TLV.

9. A vulnerability scanning system based on LLDP extension according to claim 1 or 5, characterized in that, In the digital signature TLV, the device uses its private key to sign the hash value of all extended TLVs, and the scanning end verifies the validity of the signature through a pre-set list of device public keys. The ACK TLV response includes a sequence number, a parsing result status code, and a timestamp; The sequence number is an 8-byte unsigned integer, corresponding to the sequence number of the original message, used for message matching; the parsing result status code is 0 for success, 1 for partial error, 2 for format error, 3 for authentication failure, and 4 for timeout. The timestamp is an 8-byte unsigned integer, which is the Unix timestamp generated by ACK.

10. A vulnerability scanning system based on LLDP extensions according to claim 1, characterized in that, The default deduplication rule for the device information database is to deduplicat based on "device ID + timestamp"; The path planning module uses Dijkstra's algorithm; the topology-related information in the topology TLV includes link bandwidth and delay information. The vulnerability matching engine interfaces with a vulnerability database such as the CVE database, the NVD public vulnerability database, or a private vulnerability database; the preset matching rules are "version matching" and "patch status comparison"; The vulnerability risk scoring information used by the risk assessment module is the CVSS score; The key asset information in the asset attribute TLV is the asset importance level; The device association information in the vulnerability association TLV is information on the criticality of upstream and downstream devices.

11. A vulnerability scanning system based on LLDP extensions according to claim 1, characterized in that, After receiving the extended LLDP message, the scanning end generates an acknowledgment message containing verification information and uses the ACK TLV response to feedback the reception status. If no response is received three times in a row, the device will shorten the transmission interval to a preset duration of seconds until the scanning end is confirmed to have successfully received the data. When multiple devices simultaneously send extended LLDP messages, causing a conflict, a "priority + random backoff" strategy is adopted. Equipment priority is determined by the asset importance level; if the priorities are the same, a random backoff time is generated based on the last 4 bits of the MAC address.

12. A vulnerability scanning method based on LLDP extensions, characterized in that, The method, applied to the vulnerability scanning system based on LLDP extensions as described in any one of claims 1 to 11, includes the following steps: S1. After the vulnerability scanner starts, it listens for LLDP packets in the network and parses the custom extended TLV field; it extracts the device asset information from the asset attribute TLV, stores it in the device information database and establishes a mapping relationship between device identifier and asset attribute; at the same time, it connects to the vulnerability database through the vulnerability matching engine to determine whether the device has vulnerability risks. If so, it marks the device risk level and prioritizes the scanning task. S2. Based on the topology-related information in the topology TLV, use the path planning algorithm to calculate the scanning path from the scanning source to each target device; if a topology change event is detected, recalculate the scanning path. S3. During the vulnerability detection process, the connection relationship between the vulnerable device and related devices is recorded in the vulnerability association TLV; the risk assessment module combines the information in the asset attribute TLV, topology TLV and vulnerability association TLV to calculate the risk value of the device according to the preset risk rating algorithm; when the vulnerability status of the related device changes, the risk recalculation of the current device is triggered.

13. A vulnerability scanning method based on LLDP extensions according to claim 12, characterized in that, It also includes LLDP extended message interaction steps: The device uses a strategy that combines periodic sending with event triggering to send extended LLDP messages. Under normal conditions, a complete message is sent once every first predetermined duration second, and a message is sent immediately when asset attributes change or topology changes. After receiving a message, the scanner returns the status via an ACK TLV response. If no response is received three times in a row, the device will shorten the transmission interval to the second predetermined duration seconds. When multiple devices have conflicting messages, priority is determined according to the asset importance level. If the priorities are the same, a random backoff time is generated based on the last 4 bits of the MAC address, and messages from higher-priority devices are transmitted first.

Images