Abnormal port auditing method in mixed service environment of metropolitan area network and related device

Abstract

This application provides a method and related equipment for auditing abnormal ports in a metropolitan area network (MAN) with mixed services, belonging to the fields of network communication technology and network security management technology. The method includes: collecting multi-source data from the MAN and Internet data centers; comparing a full list of ports in UP status with a list of billed ports and filtering low-traffic ports to generate a preliminary list of suspected abnormal ports; applying network rules to identify and remove trunk circuit ports; comparing the service IP addresses declared by the remaining ports with a list of billed customer service addresses to mark suspected client ports or suspected client ports awaiting confirmation; for suspected client ports awaiting confirmation, integrating network flow, authentication, authorization, and billing logs, domain name system resolution logs, and content delivery network scheduling data for behavioral feature analysis to generate port usage tags; and determining the type of downstream devices based on tag combinations and outputting the abnormal port list. This application significantly reduces the false alarm rate and improves network security management efficiency.

Description

Technical Field

[0001] This application relates to the fields of network communication technology and network security management technology, and in particular to an abnormal port auditing method and related equipment in a metropolitan area network hybrid service environment. Background Technology

[0002] With the development of network technology, the services carried by metropolitan area networks (MANs) are becoming increasingly complex. In addition to traditional home broadband and IPTV, IDC services, PCDN, and various leased line services are mixed in. In this mixed service environment, it is difficult to detect the act of illegally providing IDC services by opening ports or connecting unmanaged devices.

[0003] Current technology primarily relies on comparing the billing ports of managed IDC core routers with their service addresses. For example, it extracts a list of billing-configured ports on the IDC core router and compares it with the actual advertised service IP addresses on those ports; if a match is found, it's considered normal; otherwise, it's marked as abnormal. However, this method has significant drawbacks: 1) Inability to effectively cover abnormal behavior on the metropolitan area network side: Existing technologies mainly target core IDC equipment and lack monitoring methods for unauthorized ports on a large number of access devices (such as BAS and aggregation switches) on the metropolitan area network side.

[0004] 2) There is a risk of omission for ports that are not in the billing address list but are actually customer business ports: Some customers may conduct business directly through dedicated lines or metropolitan area network connection ports, but they are not included in the IDC billing system and cannot be discovered by traditional comparison methods.

[0005] 3) Lack of ability to detect unmanaged client devices connected to the port: Existing technology cannot identify unmanaged client devices connected to the port, such as privately connected servers or unregistered PCDN nodes. Summary of the Invention

[0006] The main purpose of this application is to propose a method, device, electronic device, storage medium and program product for auditing abnormal ports in a metropolitan area network (MAN) hybrid service environment. The aim is to systematically solve the core pain point of difficulty in discovering, judging and managing abnormal unbilled ports in the current management of MAN and IDC networks by telecom operators.

[0007] To achieve the above objectives, one aspect of this application proposes a method for auditing abnormal ports in a metropolitan area network (MAN) hybrid service environment, the method comprising: Collect multi-source data from metropolitan area network and Internet data center network devices. The multi-source data includes full configuration information, port traffic data, network flow data, billing port list, authentication, authorization and billing logs, domain name system resolution logs and content delivery network scheduling data. Based on the full configuration information, a full list of ports in UP status is generated. The full list of ports in UP status is compared with the list of billed ports, billed ports are removed, and low-traffic ports are filtered based on a preset port flow rate threshold to generate a preliminary list of suspected abnormal ports. The network rules are applied to compare the list of suspected abnormal ports, identify and mark the trunk circuit ports, and remove the trunk circuit ports from the list of suspected abnormal ports to generate a list of non-trunk suspected abnormal ports. The service Internet Protocol address announced by the port in the list of suspected abnormal non-relay ports is compared with the list of billed customer service addresses. If there is an overlap, the suspected abnormal non-relay port is marked as a suspected client port. If there is no overlap, the suspected abnormal non-relay port is marked as a suspected client port to be confirmed. For the suspected client ports to be confirmed, behavioral feature analysis is performed by integrating the network flow data, the authentication, authorization and billing logs, the domain name system resolution logs and the content delivery network scheduling data to generate port usage tags; Based on the port usage tag or a combination of the port usage tags, the type of downstream device is comprehensively determined, and then an abnormal port list is generated.

[0008] In some embodiments, the preset port flow rate threshold is less than 100 megabits per second.

[0009] In some embodiments, the network rule is a two-way interconnection address and mask matching rule.

[0010] In some embodiments, the step of performing behavioral feature analysis on the suspected client port to be confirmed, by integrating the network flow data, the authentication, authorization, and billing logs, the Domain Name System (DNS) resolution logs, and the content delivery network (CDN) scheduling data, to generate a port usage tag, specifically includes: Extract source Internet Protocol addresses whose traffic exceeds a dynamically adjustable threshold from the network flow data, and filter out target Internet Protocol addresses whose outflow traffic is greater than or equal to the inflow traffic. If the target Internet Protocol address belongs to a billed service address, it is determined that the downstream device of the port of the target Internet Protocol address provides Internet data center services, and the port usage tag is marked as a customer; If the target Internet Protocol address is found in the authentication, authorization, and billing log, it is determined that the downstream device of the port of the target Internet Protocol address is a home broadband or Internet Protocol TV service. The port usage tag is marked as home broadband or IPTV, and the traffic characteristics of the target Internet Protocol address are checked. If the outflow traffic is greater than or equal to the inflow traffic, the port corresponding to the target Internet Protocol address is marked as suspected peer-to-peer content delivery network behavior. If a resolution record for the target Internet Protocol address is found in the Domain Name System (DNS) resolution log, it is determined that the downstream device of the port of the target Internet Protocol address provides Internet services to the outside world, and the port usage tag is marked as customer; Analyze the network flow data of the first few peer Internet Protocol addresses that interact with the target Internet Protocol address, and query the content delivery network scheduling data. If the peer Internet Protocol address belongs to a content delivery network node, determine that the downstream device of the port of the target Internet Protocol address is connected to the content delivery network to provide services, and mark the port usage tag as a client.

[0011] In some embodiments, the determination of the downstream device type based on the port usage tag or a combination of the port usage tags specifically includes: If the port usage label only contains "customer", then the downstream device is determined to be a suspected unmanaged customer device; If the port usage label includes both customer and broadband or IPTV, the downstream device is determined to be a suspected unmanaged metropolitan area network device. If the port usage label only includes home broadband or IPTV, then the downstream device type is determined to be a normal service port.

[0012] In some embodiments, the multi-source data may also include port traffic flow rate information collected by Simple Network Management Protocol.

[0013] In some embodiments, the abnormal port list includes port identifiers, downstream device types, and corresponding analysis evidence, including traffic characteristics, authentication records, or domain name system resolution records.

[0014] To achieve the above objectives, another aspect of this application proposes an abnormal port auditing device for a metropolitan area network (MAN) mixed service environment, the device comprising: The data acquisition module is used to collect multi-source data from metropolitan area network and Internet data center network devices. The multi-source data includes full configuration information, port traffic data, network flow data, billing port list, authentication, authorization and billing logs, domain name system resolution logs and content delivery network scheduling data. The suspected abnormal port screening module is used to generate a full list of UP status ports based on the full configuration information, compare the full list of UP status ports with the billing port list, remove billed ports, and filter low-traffic ports based on a preset port flow rate threshold to generate a preliminary list of suspected abnormal ports. The relay port intelligent filtering module is used to compare the list of suspected abnormal ports with network rules, identify and mark the relay circuit ports, remove the relay circuit ports from the list of suspected abnormal ports, and generate a list of non-relay suspected abnormal ports. The service address overlap judgment module is used to compare the service Internet Protocol address announced by the port in the list of suspected abnormal non-relay ports with the service address list of billed customers. If there is an overlap, the suspected abnormal non-relay port is marked as a suspected client port. If there is no overlap, the suspected abnormal non-relay port is marked as a suspected client port to be confirmed. The multi-dimensional deep behavior analysis module is used to perform behavioral feature analysis on the suspected client port to be confirmed by integrating the network flow data, the authentication, authorization and billing logs, the domain name system resolution logs and the content distribution network scheduling data, and generate port usage tags. The device type determination and output module is used to comprehensively determine the type of downstream devices based on the port usage tag or a combination of the port usage tags, and then generate an abnormal port list.

[0015] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0016] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0017] To achieve the above objectives, another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0018] The embodiments of this application include at least the following beneficial effects: This application provides a method, apparatus, electronic device, storage medium, and program product for auditing abnormal ports in a metropolitan area network (MAN) mixed service environment. This solution uses multi-source data from the MAN and Internet data centers as the basis for analysis. First, it performs initial screening using billing port comparison and flow rate thresholds to quickly eliminate a large number of compliant and non-traffic ports, significantly narrowing the analysis scope and reducing computational overhead. Then, it identifies and eliminates trunk circuit ports through network rules, effectively avoiding the defect of misreporting network interconnection ports as service ports and significantly reducing the false alarm rate. Based on this, by... The system compares the business IP with the list of billed customer addresses to further distinguish between known customer services and unidentified targets, thus focusing in-depth analysis resources on the most suspicious ports. For ports to be confirmed, it integrates network flow, AAA authentication logs, DNS resolution logs, and CDN scheduling data for multi-dimensional behavioral analysis. This can penetrate the limitations of single logs or traffic data and accurately identify hidden violations such as PCDN, unauthorized IDC, and privately set up web services. Finally, it determines the type of downstream device based on the combination of port usage tags and outputs a list of abnormal ports with a complete chain of evidence, providing clear basis for operation and maintenance personnel to take action. Attached Figure Description

[0019] Figure 1 This is a flowchart of an abnormal port auditing method provided in an embodiment of this application for a metropolitan area network in a mixed service environment; Figure 2 yes Figure 1 The flowchart of step S105 in the process; Figure 3 This is an overall flowchart of the metropolitan area network abnormal port auditing method provided in the embodiments of this application; Figure 4 This is a detailed logic diagram of the metropolitan area network abnormal port audit and analysis process provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of an abnormal port auditing device in a metropolitan area network hybrid service environment provided in an embodiment of this application; Figure 6 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0022] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0023] 1) IDC (Internet Data Center): refers to the physical facilities used to house computer systems, servers, storage and related network equipment.

[0024] 2) Metropolitan Area Network (MAN): refers to a medium-sized computer communication network that interconnects multiple local area networks within a city or region (usually covering several kilometers to tens of kilometers).

[0025] 3) AAA (Authentication, Authorization, and Accounting): This is a technology that tracks and audits network resource access behavior and ensures network security and compliance by recording authentication, authorization, and accounting information of users or devices.

[0026] 4) DNS (Domain Name System): This is a technical data system that monitors network traffic, analyzes access behavior, diagnoses network faults, and discovers potential security threats by recording the domain name query and response process between clients and DNS servers.

[0027] With the rapid development of information technology, the Internet has deeply integrated into all aspects of social and economic life. Metropolitan Area Networks (MANs), as a key infrastructure connecting users and the backbone network, undertake the tasks of aggregating, exchanging, and forwarding massive amounts of data. In recent years, the types of services carried by MANs have become increasingly complex and diverse. In addition to traditional home broadband and IPTV services, they also widely carry Internet Data Center (IDC) services, leased line services, PCDN (P2P Content Delivery Network) services, and various enterprise access services. In this "mixed service" environment, the number of ports in MANs has increased exponentially, and the port relationships are intricate, posing unprecedented challenges to network management.

[0028] A prominent problem that has long plagued telecom operators and network management departments is the difficulty in promptly detecting, accurately characterizing, and effectively proving the unauthorized provision of IDC or PCDN services by opening network device ports or connecting to unmanaged equipment. This behavior not only leads to a serious waste of operators' bandwidth resources and a direct loss of revenue (for example, unauthorized PCDN services consume large amounts of home broadband uplink bandwidth without paying corresponding IDC service fees), but also undermines the principle of fair network usage, reduces the network experience quality for normal users, and may even become a springboard for network attacks, posing serious security risks.

[0029] Currently, existing technical solutions to the above problems mainly have the following drawbacks: First, the coverage is limited, creating management blind spots. Existing technologies mostly focus on managed IDC core routers and their billing ports. By comparing the billing port list with the device's UP ports, abnormal ports on managed IDC devices can be identified. However, a large number of violations occur on access devices (such as BRAS and aggregation switches) on the metropolitan area network side, and even on user-side devices. These devices are not traditional IDC billing targets, and the existing auditing system cannot effectively cover them, creating a significant "blind spot" effect.

[0030] Second, relying on a single data source results in high false positive and false negative rates. Some existing solutions attempt to detect anomalies through traffic analysis, such as setting traffic thresholds, with ports exceeding the threshold being marked as abnormal. This method is extremely crude and cannot distinguish between normal high-traffic services (such as enterprise leased lines and video services) and illegal PCDN services, leading to a large number of false positives. At the same time, some hidden low-traffic illegal ports (such as privately opened ports used as management channels) are easily missed. Other solutions rely on manual experience for spot checks, but neither the efficiency nor the accuracy can meet the actual needs of large-scale metropolitan area networks.

[0031] Third, there is a lack of deep insight into the nature of the business. With the widespread use of encryption protocols, traditional deep packet inspection (DPI) techniques struggle to penetrate encrypted traffic to identify the type of business. For example, PCDN traffic is difficult to distinguish from ordinary HTTPS traffic at the transport layer. Existing technologies cannot effectively answer the core question of "what service is the traffic on this port essentially providing?" This makes it difficult to determine the nature of any violations even when abnormal ports are discovered, thus failing to provide strong support for subsequent handling and evidence collection.

[0032] Fourth, it cannot effectively identify unmanaged devices. In real-world network environments, there are numerous customer devices and network elements that are not registered in the network management or billing systems. These devices connect to the metropolitan area network through unauthorized ports and provide services externally. Due to the lack of billing and network management information, traditional methods are completely incapable of detecting them.

[0033] In view of this, this application provides a method, device, electronic device, storage medium, and program product for abnormal port auditing in a metropolitan area network (MAN) mixed service environment. This solution replaces inefficient manual screening by constructing a cascaded filtering model that integrates multi-source data fusion and logical discrimination, achieving automated and precise abnormal port auditing, significantly improving operational efficiency and accuracy. Furthermore, it deeply integrates multi-dimensional data such as network flow, authentication (AAA), domain name resolution (DNS), and content delivery network (CDN) to intelligently determine the nature of abnormal port services, accurately distinguishing between unbilled customer dedicated line services, illegal PCDN services, and self-used internet services, providing a clear basis for subsequent handling. This effectively controls network resource and operational losses, blocks revenue loss by cleaning up various "gray" services, protects the legitimate business interests of enterprises, purifies the network environment, and ensures network quality and security for normal users. Simultaneously, by discovering and handling ports and devices that are not reported for external services, it reduces network blind spots and security risks, enhances network visibility, controllability, and manageability, and meets the compliance requirements of national cyberspace security governance.

[0034] The abnormal port auditing method for a metropolitan area network (MAN) in a mixed service environment provided in this application relates to the fields of network communication technology and network security management technology. The abnormal port auditing method for a MAN in a mixed service environment provided in this application can be applied to a terminal, a server, or software running on a terminal or server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or vehicle terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing the abnormal port auditing method for a MAN in a mixed service environment, but is not limited to the above forms.

[0035] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0036] Figure 1 This is an optional flowchart of an abnormal port auditing method provided in a metropolitan area network hybrid service environment according to an embodiment of this application. Figure 1 The method may include, but is not limited to, steps S101 to S106.

[0037] Step S101, Data Acquisition Step: Collect multi-source data from metropolitan area network and Internet data center network devices. The multi-source data includes full configuration information, port traffic data, network flow data, billing port list, authentication, authorization and billing logs, domain name system resolution logs and content delivery network scheduling data. Step S102, preliminary screening of suspected abnormal ports: Generate a full list of ports in UP state based on the full configuration information, compare the full list of ports in UP state with the billing port list, remove billed ports, and filter low-traffic ports based on a preset port flow rate threshold to generate a preliminary list of suspected abnormal ports. Step S103, Intelligent filtering step for relay ports: The network rules are applied to compare the list of suspected abnormal ports, identify and mark the relay circuit ports, and remove the relay circuit ports from the list of suspected abnormal ports to generate a list of non-relay suspected abnormal ports. Step S104, Service Address Overlap Judgment Step: Compare the service Internet Protocol address announced by the port in the list of suspected abnormal non-relay ports with the list of billed customer service addresses. If there is an overlap, mark the suspected abnormal non-relay port as a suspected client port. If there is no overlap, mark the suspected abnormal non-relay port as a suspected client port to be confirmed. Step S105, Multi-dimensional Deep Behavioral Analysis Step: For the suspected client port to be confirmed, the network flow data, the authentication, authorization and billing logs, the domain name system resolution logs and the content delivery network scheduling data are integrated to perform behavioral feature analysis and generate port usage tags; Step S106, Device type determination and output step: Based on the port usage tag or a combination of the port usage tags, comprehensively determine the downstream device type and generate an abnormal port list.

[0038] Steps S101 to S106 of this embodiment use multi-source data from metropolitan area networks and internet data centers as the basis for analysis. First, billing port comparison and flow rate thresholds are used for initial screening to quickly eliminate a large number of compliant and non-traffic ports, significantly narrowing the analysis scope and reducing computational overhead. Then, trunk circuit ports are identified and eliminated through dual-end interconnection address and mask rules, effectively avoiding the defect of misreporting network interconnection ports as service ports and significantly reducing the false alarm rate. On this basis, by overlapping and comparing the service IPs of the remaining ports with the list of billed customer addresses, known customer services and unidentified targets to be confirmed are further distinguished, thereby focusing in-depth analysis resources on the most suspicious ports. For the ports to be confirmed, network flow, AAA authentication logs, DNS resolution logs and CDN scheduling data are integrated for multi-dimensional behavioral analysis, which can penetrate the limitations of single logs or traffic data and accurately identify hidden violations such as PCDN, illegal IDC, and privately set up web services. Finally, the type of downstream device is determined based on the combination of port usage tags, and an abnormal port list with a complete chain of evidence is output, providing clear handling basis for operation and maintenance personnel. In summary, the aforementioned cascading filtering and multi-source fusion technologies work together in a progressive manner to achieve full coverage, high precision, and automated auditing of unauthorized ports and unmanaged devices in a mixed business environment of metropolitan area networks. This significantly reduces false alarms and missed alarms while improving operational efficiency and providing accurate qualitative support for subsequent business governance, thereby effectively preventing the loss of operating revenue and eliminating network security blind spots.

[0039] Please see Figure 2 In some embodiments, step S105 may include, but is not limited to, steps S201 to S205: Step S201: Extract source Internet Protocol addresses with traffic exceeding a dynamically adjustable threshold from the network flow data, and filter out target Internet Protocol addresses with outflow traffic greater than or equal to inflow traffic. Step S202: If the target Internet Protocol address belongs to a billed service address, then determine that the downstream device of the port of the target Internet Protocol address provides Internet Data Center services, and mark the port usage tag as a customer; Step S203: If the target Internet Protocol address is found in the authentication, authorization, and billing log, it is determined that the downstream device of the port of the target Internet Protocol address is a home broadband or Internet Protocol TV service. The port usage tag is marked as home broadband or IPTV. The traffic characteristics of the target Internet Protocol address are checked. If the outflow traffic is greater than or equal to the inflow traffic, the port corresponding to the target Internet Protocol address is marked as suspected peer-to-peer content delivery network behavior. Step S204: If a resolution record for the target Internet Protocol address is found in the Domain Name System resolution log, it is determined that the downstream device of the port of the target Internet Protocol address provides Internet services to the outside world, and the port usage tag is marked as customer; Step S205: Analyze the first few peer Internet Protocol addresses that interact with the target Internet Protocol address in the network flow data, and query the content delivery network scheduling data. If the peer Internet Protocol address belongs to a content delivery network node, determine that the port downstream device of the target Internet Protocol address is connected to the content delivery network to provide services, and mark the port usage tag as a client.

[0040] Steps S201 to S205 as shown in the embodiments of this application use "asymmetric traffic characteristics (outflow ≥ inflow)" as the core screening condition, combined with cross-verification of multi-source data from AAA, DNS, and CDN, to achieve accurate identification and classification of service-type businesses (IDC, PCDN, self-built CDN, Web services), providing a clear and traceable chain of evidence for subsequent device type determination and handling, and significantly improving the depth and accuracy of abnormal port audits.

[0041] In some embodiments, step S106 may include, but is not limited to, steps S301 to S303: Step S301: If the port usage label only contains "customer", then the downstream device is determined to be a suspected unmanaged customer device. Step S302: If the port usage label includes both customer and broadband or IPTV, then the downstream device is determined to be a suspected unmanaged metropolitan area network device. Step S303: If the port usage label only includes home broadband or IPTV, then the downstream device type is determined to be a normal service port.

[0042] Steps S301 to S303 of this application embodiment map the abstract labels (customer, broadband, or IPTV) output by the multi-dimensional deep behavioral analysis layer into three types of devices with clear management significance through specific and quantifiable combination rules. This provides maintenance personnel with a direct and actionable basis for handling: for "unmanaged customer devices", customer tracing and billing supplementation processes need to be initiated; for "unmanaged metropolitan area network devices (such as BAS and other network elements)", the management status and configuration compliance of the devices need to be checked; and for "normal business ports", they are directly ignored to avoid invalid interference. This effectively solves the pain points of unclear identification of abnormal ports and unclear handling direction in traditional solutions, and realizes a complete closed loop from "discovering anomalies" to "determining the type" to "guiding handling", significantly improving the automation level and operability of network security management processes.

[0043] The solutions of the embodiments of this application will be described in detail below with reference to the accompanying drawings and specific application examples.

[0044] This embodiment provides a method for auditing abnormal ports in a metropolitan area network (MAN) mixed service environment. For example... Figure 3 As shown, the method includes the following steps: S1: Data Acquisition and Preprocessing Layer The system collects full configuration information (including port status, IP address, subnet mask, etc.) of metropolitan area network (MAN) and data center (IDC) network devices, port traffic flow rate information (obtained via SNMP protocol), network flow data (NetFlow / sFlow / IPFIX), billing system information (list of billed ports and corresponding service IP address ranges), AAA authentication logs (recording user or device authentication, authorization, and billing information), DNS resolution logs (domain name query records initiated by clients), and CDN scheduling data (CDN node IP address database and scheduling mapping relationships). All data is cleaned and normalized before being stored in a unified data platform to build a unified data analysis foundation.

[0045] S2: Preliminary screening layer for suspected abnormal ports Based on device configuration information, all ports with a management status of UP (enabled) are filtered out, generating a full list of UP ports. This list is compared with the billing system's list of billed ports, and billed ports are removed. Then, for the remaining ports, based on port flow rate information collected by SNMP, a flow rate threshold is set (e.g., 100Mbps in this embodiment), filtering out ports with flow rates below this threshold (these ports typically have no service traffic or only extremely low traffic, and are unlikely to be illegal service ports). After these two filtering steps, a preliminary list of suspected abnormal ports is output.

[0046] S3: Smart Filtering Layer for Relay Ports In metropolitan area networks (MANs), there are numerous trunk circuit ports used for interconnecting network devices. These ports do not directly face customer services and should not be considered abnormal. This embodiment uses a dual-end interconnection address and mask matching rule to identify these ports: for the IP address and mask configured on the port, if the interface IP address of the peer device belongs to the same subnet, and both ends are network devices (determined by device role identification), then the port is identified as a trunk circuit port. All identified trunk ports are removed from the list of suspected abnormal ports, generating a list of non-trunk suspected abnormal ports. This step significantly narrows the target scope for subsequent in-depth analysis and reduces false positives.

[0047] S4: Service Address Overlap Analysis Layer The service IP addresses advertised by non-relay suspected abnormal ports (usually the IP range advertised by the subnet where the port is located or the device connected to the port) are compared with the list of billed customer service addresses. If there is an overlap (i.e., the IP address range has been recorded by the billing system as a legitimate service address of a certain customer), the port is directly marked as a "suspected client port" and proceeds to the next process; if there is no overlap, it is marked as a "suspected client port to be confirmed" and used as a key target for in-depth analysis.

[0048] S5: Multi-dimensional Deep Behavioral Analysis Layer For "suspected client ports awaiting confirmation," in-depth behavioral feature analysis is conducted by integrating multi-dimensional data such as Flow, AAA, DNS, and CDN. (Refer to...) Figure 4 The detailed process includes: 1) Flow Feature Analysis: From NetFlow data, extract source IPs whose traffic exceeds a preset dynamic threshold (e.g., 120% of the daily average traffic) across all source IPs under this port, and further filter out IPs where outflow traffic (traffic originating from this IP) is greater than or equal to inflow traffic (traffic destined for this IP). This feature indicates that this IP primarily acts as a content provider, rather than a typical consumer.

[0049] 2) Business Attribution Analysis: For each suspicious IP selected, perform the following judgments in sequence: If the IP address belongs to a billed service address, it is determined that the device connected to that port provides IDC services and is marked as a "customer".

[0050] Otherwise, query the AAA log: if an authentication record for the IP exists (indicating that the IP belongs to a home broadband or IPTV user), mark it as "home broadband or IPTV" and further check its traffic characteristics: if outflow is greater than or equal to inflow, mark its behavior as "suspected PCDN".

[0051] Otherwise, check the DNS resolution log: if there are domain name resolution records initiated by this IP (especially a large number of resolution requests for different domain names), it indicates that this IP provides Internet services to the outside world (such as acting as a web server, proxy, etc.), and is marked as "client".

[0052] Finally, analyze the Top N peer IPs (e.g., Top 10) that interact with this IP in the Flow data, query the CDN scheduling data, and if it is found that most of the peer IPs belong to CDN nodes, then determine that this IP is connected to a CDN to provide services (e.g., as a PCDN node or a self-built CDN) and mark it as a "customer".

[0053] S6: Device Type Determination and Output Layer Based on the usage label (which may be "customer", "home broadband or IPTV" or a combination thereof) generated for this port by the deep analysis layer, the type of downstream device is determined comprehensively: 1) "Customer": Determine if the downstream device is suspected to be an unmanaged customer device (such as privately connected servers or unreported IDC devices).

[0054] 2) "Customer + Home Broadband or IPTV": Determine the downstream device as a suspected unmanaged metropolitan area network device (e.g., a device that illegally uses home broadband access to carry out PCDN services, or an abnormal port of a downstream BAS or other network element device).

[0055] 3) "Home broadband or IPTV": This is considered a normal service port and is ignored.

[0056] Finally, an abnormal port list is generated, which includes port identifiers (device name + port number), downstream device types, and all supporting evidence (such as traffic characteristic screenshots, DNS resolution records, peer IP lists, etc.), and is sent to the local authorities for confirmation and handling.

[0057] The following is a specific case study of metropolitan area network port auditing.

[0058] In a telecommunications operator's metropolitan area network, there is a port A (located on the aggregation switch GigabitEthernet0 / 1). This port is not listed in the billing port list, and its flow rate is recorded as 500Mbps via SNMP. Perform an audit according to the scheme in this embodiment: 1) Initial screening: Port A is not billed and its flow rate is greater than 100Mbps, so it is included in the preliminary list of suspected abnormal ports.

[0059] 2) Trunk Filtering: Check the configuration of port A. Its peer IP address is 10.1.1.2 / 30 and its local IP address is 10.1.1.1 / 30. Both ends of the device are switches, which meets the trunk rule. However, in this example, port A is not actually a trunk port (assuming that it does not meet the trunk rule after the check, or the rule base does not mark it as a trunk). Therefore, it is determined to be a non-trunk port.

[0060] 3) Address comparison: The IP address range of the service announced by port A is 221.236.13.0 / 24. After querying the billed customer service address database, no overlap was found, so it is marked as "suspected client port to be confirmed".

[0061] 4) In-depth analysis: Analyzing the NetFlow data of port A, it was found that the outflow traffic of source IP 221.236.13.95 was 480Mbps and the inflow traffic was 20Mbps, which satisfies the characteristic of outflow ≥ inflow.

[0062] 4.1) Check billing data: This IP is not in the billed address database.

[0063] 4.2) AAA log query: No PPPoE or IPoE authentication record was found for IP 221.236.13.95, excluding home broadband / IPTV services.

[0064] 4.3) Query DNS logs: The IP has a large number of different domain name resolution records in the last 24 hours, and the resolution request frequency is high, indicating that the IP provides Internet services to the outside world.

[0065] Analysis of the top 10 peer IPs revealed that 8 of them belong to known CDN nodes (based on CDN node database matching).

[0066] 5) Judgment and Output: Based on the DNS resolution records and CDN node matching results, it is determined that the purpose of port A is "customer," and its downstream device is suspected to be an unmanaged customer device used to provide Internet services to the outside world (possibly a privately set up web server or PCDN node). Port A and its analysis evidence (traffic characteristics, DNS records, and peer CDN node list) are added to the anomaly list and distributed to the province for verification.

[0067] After on-site verification by local engineers, it was confirmed that an unregistered server was connected to port A and was running a commercial video distribution service. Subsequent actions stopped the violation, and compliant IDC services were provided to the client. This case verifies the effectiveness of this embodiment.

[0068] In summary, the method of this application, compared with the prior art, has at least the following advantages and beneficial effects: 1) High accuracy and traceability: By integrating multi-source data such as device configuration, billing, AAA, DNS, and CDN, a complete chain of evidence is constructed for cross-verification, significantly reducing false positives and false negatives caused by analysis of a single data source. Furthermore, the output list of abnormal ports includes detailed evidence such as traffic characteristics, authentication records, and DNS resolution records, providing strong support for subsequent manual verification and handling.

[0069] 2) Full coverage capability: This invention not only covers the core equipment of the managed IDC, but also effectively discovers the privately opened ports on the access equipment on the metropolitan area network side (such as BAS and aggregation switches), as well as the unmanaged customer equipment and non-compliant network element equipment connected downstream. It truly realizes three-dimensional auditing in the mixed business environment of the metropolitan area network and eliminates management blind spots.

[0070] 3) Automation and High Efficiency: Through a cascading filtering process of "initial screening - relay filtering - address comparison - in-depth analysis," the scope of analysis is narrowed down step by step, avoiding the problem of computing resource explosion caused by comprehensive in-depth analysis of massive ports. The standardized analysis process reduces manual intervention, supports routine, large-scale port monitoring, and significantly improves operation and maintenance efficiency.

[0071] 4) Deep Business Insight Capabilities: Based on the asymmetric traffic characteristic of "outflow traffic ≥ inflow traffic," it can penetrate application layer encryption and accurately identify service-oriented businesses aimed at content distribution (such as PCDN, illegal IDC, self-built CDN, etc.). By combining DNS logs and CDN node library matching, it can clearly determine the business affiliation, providing precise direction for subsequent governance.

[0072] 5) Dual economic and security value: By cleaning up illegal PCDNs and unauthorized IDCs, it directly recovers huge losses of bandwidth resources and operating revenue for operators; at the same time, it discovers and deals with unmanaged equipment, eliminates potential attack springboards and security vulnerabilities, significantly enhances the network's "knowable, controllable, and manageable" capabilities, and meets the compliance requirements of national cyberspace security governance.

[0073] Please see Figure 5 This application also provides an abnormal port auditing device for a metropolitan area network mixed service environment, which can implement the above method. The device includes: The data acquisition module is used to collect multi-source data from metropolitan area network and Internet data center network devices. The multi-source data includes full configuration information, port traffic data, network flow data, billing port list, authentication, authorization and billing logs, domain name system resolution logs and content delivery network scheduling data. The suspected abnormal port screening module is used to generate a full list of UP status ports based on the full configuration information, compare the full list of UP status ports with the billing port list, remove billed ports, and filter low-traffic ports based on a preset port flow rate threshold to generate a preliminary list of suspected abnormal ports. The relay port intelligent filtering module is used to compare the list of suspected abnormal ports with network rules, identify and mark the relay circuit ports, remove the relay circuit ports from the list of suspected abnormal ports, and generate a list of non-relay suspected abnormal ports. The service address overlap judgment module is used to compare the service Internet Protocol address announced by the port in the list of suspected abnormal non-relay ports with the service address list of billed customers. If there is an overlap, the suspected abnormal non-relay port is marked as a suspected client port. If there is no overlap, the suspected abnormal non-relay port is marked as a suspected client port to be confirmed. The multi-dimensional deep behavior analysis module is used to perform behavioral feature analysis on the suspected client port to be confirmed by integrating the network flow data, the authentication, authorization and billing logs, the domain name system resolution logs and the content distribution network scheduling data, and generate port usage tags. The device type determination and output module is used to comprehensively determine the type of downstream devices based on the port usage tag or a combination of the port usage tags, and then generate an abnormal port list.

[0074] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0075] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0076] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0077] Please see Figure 6 , Figure 6 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 601 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 602 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 602 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 602 and is called and executed by the processor 601 using the methods described in the embodiments of this application. The input / output interface 603 is used to implement information input and output; The communication interface 604 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 605 transmits information between various components of the device (e.g., processor 601, memory 602, input / output interface 603, and communication interface 604); The processor 601, memory 602, input / output interface 603, and communication interface 604 are connected to each other within the device via bus 605.

[0078] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0079] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0080] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0081] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0082] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented in the embodiments of this program product are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments. The executable computer program code or "code" used to perform the various embodiments can be written in high-level programming languages ​​such as C, C++, Python, Smalltalk, Java, JavaScript, Visual Basic, Structured Query Language (e.g., Transact-SQL), Perl, or in various other programming languages.

[0083] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0084] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0085] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0086] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0087] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0088] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0089] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0090] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0091] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0092] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0093] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for auditing abnormal ports in a metropolitan area network (MAN) hybrid service environment, characterized in that, The method includes the following steps: Collect multi-source data from metropolitan area network and Internet data center network devices. The multi-source data includes full configuration information, port traffic data, network flow data, billing port list, authentication, authorization and billing logs, domain name system resolution logs and content delivery network scheduling data. Based on the full configuration information, a full list of ports in UP status is generated. The full list of ports in UP status is compared with the list of billed ports, billed ports are removed, and low-traffic ports are filtered based on a preset port flow rate threshold to generate a preliminary list of suspected abnormal ports. The network rules are applied to compare the list of suspected abnormal ports, identify and mark the trunk circuit ports, and remove the trunk circuit ports from the list of suspected abnormal ports to generate a list of non-trunk suspected abnormal ports. The service Internet Protocol address announced by the port in the list of suspected abnormal non-relay ports is compared with the list of billed customer service addresses. If there is an overlap, the suspected abnormal non-relay port is marked as a suspected client port. If there is no overlap, the suspected abnormal non-relay port is marked as a suspected client port to be confirmed. For the suspected client ports to be confirmed, behavioral feature analysis is performed by integrating the network flow data, the authentication, authorization and billing logs, the domain name system resolution logs and the content delivery network scheduling data to generate port usage tags; Based on the port usage tag or a combination of the port usage tags, the type of downstream device is comprehensively determined, and then an abnormal port list is generated.

2. The method according to claim 1, characterized in that, The preset port flow rate threshold is less than 100 megabits per second.

3. The method according to claim 1, characterized in that, The network rules are dual-end interconnection address and mask matching rules.

4. The method according to claim 1, characterized in that, The process involves analyzing the behavioral characteristics of the suspected client port to be confirmed, integrating network flow data, authentication, authorization, and billing logs, domain name system resolution logs, and content delivery network scheduling data to generate a port usage tag. Specifically, this includes: Extract source Internet Protocol addresses whose traffic exceeds a dynamically adjustable threshold from the network flow data, and filter out target Internet Protocol addresses whose outflow traffic is greater than or equal to the inflow traffic. If the target Internet Protocol address belongs to a billed service address, it is determined that the downstream device of the port of the target Internet Protocol address provides Internet data center services, and the port usage tag is marked as a customer; If the target Internet Protocol address is found in the authentication, authorization, and billing log, it is determined that the downstream device of the port of the target Internet Protocol address is a home broadband or Internet Protocol TV service. The port usage tag is marked as home broadband or IPTV, and the traffic characteristics of the target Internet Protocol address are checked. If the outflow traffic is greater than or equal to the inflow traffic, the port corresponding to the target Internet Protocol address is marked as suspected peer-to-peer content delivery network behavior. If a resolution record for the target Internet Protocol address is found in the Domain Name System (DNS) resolution log, it is determined that the downstream device of the port of the target Internet Protocol address provides Internet services to the outside world, and the port usage tag is marked as customer; Analyze the network flow data of the first few peer Internet Protocol addresses that interact with the target Internet Protocol address, and query the content delivery network scheduling data. If the peer Internet Protocol address belongs to a content delivery network node, determine that the downstream device of the port of the target Internet Protocol address is connected to the content delivery network to provide services, and mark the port usage tag as a client.

5. The method according to claim 4, characterized in that, The determination of the downstream device type based on the port usage tag or a combination of the port usage tags is as follows: If the port usage label only contains "customer", then the downstream device is determined to be a suspected unmanaged customer device; If the port usage label includes both customer and broadband or IPTV, the downstream device is determined to be a suspected unmanaged metropolitan area network device. If the port usage label only includes home broadband or IPTV, then the downstream device type is determined to be a normal service port.

6. The method according to claim 1, characterized in that, The multi-source data also includes port traffic flow rate information collected by the Simple Network Management Protocol.

7. The method according to claim 1, characterized in that, The abnormal port list includes port identifiers, downstream device types, and corresponding analysis evidence, which includes traffic characteristics, authentication records, or domain name system resolution records.

8. An abnormal port auditing device for a metropolitan area network in a mixed service environment, characterized in that, The device includes: The data acquisition module is used to collect multi-source data from metropolitan area network and Internet data center network devices. The multi-source data includes full configuration information, port traffic data, network flow data, billing port list, authentication, authorization and billing logs, domain name system resolution logs and content delivery network scheduling data. The suspected abnormal port screening module is used to generate a full list of UP status ports based on the full configuration information, compare the full list of UP status ports with the billing port list, remove billed ports, and filter low-traffic ports based on a preset port flow rate threshold to generate a preliminary list of suspected abnormal ports. The relay port intelligent filtering module is used to compare the list of suspected abnormal ports with network rules, identify and mark the relay circuit ports, remove the relay circuit ports from the list of suspected abnormal ports, and generate a list of non-relay suspected abnormal ports. The service address overlap judgment module is used to compare the service Internet Protocol address announced by the port in the list of suspected abnormal non-relay ports with the service address list of billed customers. If there is an overlap, the suspected abnormal non-relay port is marked as a suspected client port. If there is no overlap, the suspected abnormal non-relay port is marked as a suspected client port to be confirmed. The multi-dimensional deep behavior analysis module is used to perform behavioral feature analysis on the suspected client port to be confirmed by integrating the network flow data, the authentication, authorization and billing logs, the domain name system resolution logs and the content distribution network scheduling data, and generate port usage tags. The device type determination and output module is used to comprehensively determine the type of downstream devices based on the port usage tag or a combination of the port usage tags, and then generate an abnormal port list.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images