An attack identification method, apparatus, electronic device, and storage medium
By detecting DNS requests and responses, DNS attacks are identified, and a blacklist is generated for automatic protection. This solves the problem of DNS load balancing attacks being difficult to detect in a timely manner, ensuring network stability and efficiency.
Patent Information
- Application Number
- CN202411449717.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-17
- Publication Date
- 2025-11-14
- Estimated Expiration
- 2044-10-17
AI Technical Summary
Existing DNS load balancing technologies are difficult to detect in a timely manner when attacked, leading to load balancing failure, increased network latency and resolution pressure, and lagging and inefficient protection measures.
By probing DNS event messages, generating probing DNS requests, determining whether the NS server's resolution service is malfunctioning and whether the requested domain name has attack characteristics, constructing DNS response packets for source tracing, generating domain name and IP address blacklists for interception, and achieving automatic protection.
Timely identification of DNS attacks ensures the effectiveness of load balancing, prevents network latency and resolution pressure, and enables automated protection and rapid response.
Smart Images

Figure CN119382952B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of network security technology, and in particular to an attack identification method, apparatus, electronic device, and storage medium. Background Technology
[0002] Domain Name System (DNS) load balancing intelligently distributes network load by utilizing the network addresses recorded by multiple Name Servers (NS) in DNS resource records. Currently, the mainstream DNS load balancing technology uses the Round-Trip Time (RTT) optimization algorithm. Its principle is to randomly initialize the RTT of all NS servers, select the NS server with the shortest RTT for priority use, and if this NS server times out, it is penalized (it will not be selected again for a period of time), and another NS server is selected as the forwarding address. A new round of RTT calculation is performed after 1800 seconds.
[0003] In DNS load balancing, if an attacker exploits the fact that certain domain names under some authoritative DNS servers cannot be resolved and do not respond, and maliciously requests these domain names, then the unresponsive NS servers will be penalized. Most of these NS servers will lose their preferred positions, and in extreme cases, only one NS server can provide service for 1800 seconds. This will cause the DNS load balancing to fail, increase the resolution pressure on the link and the corresponding authoritative DNS servers, and greatly increase network latency.
[0004] The aforementioned attacks that disrupt DNS load balancing are typically only discovered after the attack has already occurred and impacted business operations, resulting in delayed detection. Summary of the Invention
[0005] This application provides an attack identification method, apparatus, electronic device, and storage medium to promptly and effectively detect attacks that disrupt DNS load balancing.
[0006] The specific technical solutions provided in this application are as follows:
[0007] Firstly, an attack identification method is provided, the method comprising:
[0008] The probe routine resolves DNS event messages, generates a probe DNS request, and sends the probe DNS request to the NS server. The DNS event message is generated by the DNS resolver when it determines that the NS server does not respond to the original DNS request. The original DNS request contains the requested domain name, and the DNS event message contains the requested domain name and the NS request type.
[0009] Based on the NS server's response status to the probe DNS request, the probe results are determined. The probe results indicate whether the NS server's resolution service is malfunctioning and whether the requested domain name has attack characteristics.
[0010] In one possible embodiment, the probe result is determined based on the NS server's response status to the probe DNS request, including:
[0011] If no response is received from the NS server for the DNS probe request under the preset first response condition, it is determined that the NS server's resolution service is faulty and the requested domain name does not have attack characteristics.
[0012] When the NS server responds to the probing DNS request under the first response condition, it is determined that the NS server's resolution service is normal, and the original DNS request is sent to the NS server. Based on the NS server's response status to the original DNS request, it is determined whether the requested domain name has attack characteristics.
[0013] The above method can accurately detect NS servers with DNS resolution service failures.
[0014] In one possible embodiment, determining whether the requested domain name has attack characteristics based on the NS server's response status to the original DNS request includes:
[0015] If no response to the original DNS request is received from the NS server under the preset second response condition, it is determined that the requested domain name has attack characteristics;
[0016] When the second response condition is met, and the NS server's response to the original DNS request is received, it is determined that the requested domain name does not exhibit any attack characteristics.
[0017] By sending the original request packet and re-probing the NS server using the above method, it is possible to accurately determine whether the requested domain name has attack characteristics when the NS server's DNS resolution service is normal.
[0018] In one possible embodiment, after determining the probe result based on the NS server's response status to the probe DNS request, the method further includes:
[0019] Send probe results to the DNS resolver so that when the probe results indicate that the NS server's resolution service is faulty, the DNS resolver replaces the value of the first round-trip time (RTT) in the address data with the value of the second RTT and sets the value of the second RTT to 0; and when the probe results indicate that the NS server's resolution service is normal and the requested domain name has attack characteristics, the DNS resolver does not change the value of the first RTT in the address data and sets the value of the second RTT to 0.
[0020] The first RTT is the preferred RTT, and the second RTT is the newly calculated RTT.
[0021] The above methods ensure the effectiveness of DNS load balancing.
[0022] In one possible embodiment, after determining the probe result based on the NS server's response status to the probe DNS request, the method further includes:
[0023] When the detection results indicate that the requested domain name has attack characteristics, a DNS response packet is constructed and sent to the client. The DNS response packet uses the User Datagram Protocol (UDP) and the TC flag bit of the DNS response packet is set to 1.
[0024] If a target DNS request is received from the client, it is determined that the client is a legitimate user. The target DNS request uses the Transmission Control Protocol (TCP).
[0025] If no target DNS request is received from the client, the client is determined to have characteristics of a botnet.
[0026] The above method can accurately identify whether a client has the characteristics of a botnet.
[0027] In one possible embodiment, the method further includes:
[0028] Send alarm information to the DNS management platform to trigger an alert. Based on the alarm information, generate a list of domain names and a list of IP addresses, and distribute them in batches to the DNS cache server. The DNS cache server then generates a domain name blacklist and an IP address blacklist based on the domain name and IP address lists.
[0029] The alarm information may include the requested domain name, or the alarm information may include the requested domain name and the client's IP address.
[0030] The above methods can be used to intercept and block attacks on DNS caching servers, and to perform interception or rate limiting at the network entry point to ensure the stable operation of upstream DNS services.
[0031] Secondly, an attack identification device is provided, the device comprising:
[0032] The first processing module is used to detect the DNS event message in the routine, generate a probe DNS request, and send the probe DNS request to the NS server. The DNS event message is generated by the DNS resolver when it determines that the NS server does not respond to the original DNS request. The original DNS request contains the requested domain name, and the DNS event message contains the requested domain name and the NS request type.
[0033] The detection module is used to determine the detection results based on the NS server's response status to the DNS detection request. The detection results indicate whether the NS server's resolution service is malfunctioning and whether the requested domain name has attack characteristics.
[0034] In one possible embodiment, when determining the probe result based on the NS server's response status to the probe DNS request, the probe module is further configured to:
[0035] If no response is received from the NS server for the DNS probe request under the preset first response condition, it is determined that the NS server's resolution service is faulty and the requested domain name does not have attack characteristics.
[0036] When the NS server responds to the probing DNS request under the first response condition, it is determined that the NS server's resolution service is normal, and the original DNS request is sent to the NS server. Based on the NS server's response status to the original DNS request, it is determined whether the requested domain name has attack characteristics.
[0037] In one possible embodiment, when determining whether a requested domain name has attack characteristics based on the NS server's response status to the original DNS request, the detection module is further configured to:
[0038] If no response to the original DNS request is received from the NS server under the preset second response condition, it is determined that the requested domain name has attack characteristics;
[0039] When the second response condition is met, and the NS server's response to the original DNS request is received, it is determined that the requested domain name does not exhibit any attack characteristics.
[0040] In one possible embodiment, after determining the probe result based on the NS server's response status to the probe DNS request, a second processing module is further included. The second processing module is used to:
[0041] Send probe results to the DNS resolver so that when the probe results indicate that the NS server's resolution service is faulty, the DNS resolver replaces the value of the first round-trip time (RTT) in the address data with the value of the second RTT and sets the value of the second RTT to 0; and when the probe results indicate that the NS server's resolution service is normal and the requested domain name has attack characteristics, the DNS resolver does not change the value of the first RTT in the address data and sets the value of the second RTT to 0.
[0042] The first RTT is the preferred RTT, and the second RTT is the newly calculated RTT.
[0043] In one possible embodiment, after determining the probe result based on the NS server's response status to the probe DNS request, a tracing module is further included. The tracing module is used for:
[0044] When the detection results indicate that the requested domain name has attack characteristics, a DNS response packet is constructed and sent to the client. The DNS response packet uses the User Datagram Protocol (UDP) and the TC flag bit of the DNS response packet is set to 1.
[0045] If a target DNS request is received from the client, it is determined that the client is a legitimate user. The target DNS request uses the Transmission Control Protocol (TCP).
[0046] If no target DNS request is received from the client, the client is determined to have characteristics of a botnet.
[0047] In one possible embodiment, the apparatus further includes a third processing module, the third processing module being used for:
[0048] Send alarm information to the DNS management platform to trigger an alert. Based on the alarm information, generate a list of domain names and a list of IP addresses, and distribute them in batches to the DNS cache server. The DNS cache server then generates a domain name blacklist and an IP address blacklist based on the domain name and IP address lists.
[0049] The alarm information may include the requested domain name, or the alarm information may include the requested domain name and the client's IP address.
[0050] Thirdly, this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of any of the methods described in the first aspect above.
[0051] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any of the first aspects above.
[0052] Fifthly, this application provides a computer program product comprising: computer program code, which, when run on a computer, causes the computer to perform the method described in any one of the first aspects.
[0053] In this embodiment, the probing routine resolves DNS event messages, generates a probe DNS request of type NS request, and sends the probe DNS request to the NS server. The DNS event message is generated by the DNS resolver when it determines that the NS server has not responded to the original DNS request. The original DNS request includes the requested domain name. Then, based on the NS server's response status to the probe DNS request, it is determined whether the NS server's resolution service is faulty and whether the requested domain name has attack characteristics. Thus, by using the NS request type re-probing technique, it is possible to determine whether the NS server is faulty and whether the requested domain name has attack characteristics. Without affecting normal business operations, it further discovers hidden attack behaviors in the DNS resolution process, effectively and promptly detecting attacks. Attached Figure Description
[0054] Figure 1 This is a schematic diagram illustrating possible application scenarios in the embodiments of this application;
[0055] Figure 2 This is a flowchart illustrating the implementation of an attack identification method provided in this application embodiment;
[0056] Figure 3 This is a schematic diagram of the attack identification device in the embodiments of this application;
[0057] Figure 4 This is a schematic diagram of the structure of the electronic device in the embodiments of this application. Detailed Implementation
[0058] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.
[0059] The terms "first" and "second" in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising" and any variations thereof are intended to cover non-exclusive protection. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. The term "multiple" in this application can mean at least two, for example, two, three, or more, and the embodiments of this application do not impose limitations.
[0060] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These embodiments should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that in the embodiments of this application, certain existing industry solutions such as software, components, and models may be mentioned. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solutions of this application, and do not imply that the applicant has already used or necessarily used such solutions.
[0061] To facilitate understanding of the technical solutions provided in the embodiments of this application, some key terms used in the embodiments of this application will be explained below:
[0062] Round-trip time (RTT): In computer networks, it is an important performance metric that represents the total time delay from the moment the sender begins sending data until the sender receives an acknowledgment from the receiver (the receiver sends an acknowledgment immediately after receiving the data).
[0063] SRTT: In DNS resolution, SRTT is a metric used to calculate DNS resolution latency. SRTT is calculated using a specific algorithm.
[0064] NS record: This is a domain name server record used to specify which DNS server should resolve the domain name.
[0065] DNS TC flag: This flag is carried in the response message to indicate whether the response data is too large. If this flag is set, the client should initiate a TCP DNS continue request.
[0066] The design concept of the embodiments of this application is briefly introduced below:
[0067] DNS load balancing intelligently distributes network load using network addresses from multiple NS records in DNS resource records, reducing network congestion and ensuring the availability of critical enterprise applications. Currently, the mainstream DNS load balancing technology uses the RTT (Rate-Trip Time) optimization algorithm. Its principle is to randomly initialize the RTT of all NS servers, select the NS server with the shortest RTT for priority use, and if this NS server times out, it is penalized (it will not be selected again for a period of time), and another NS server is selected as the forwarding address. A new round of RTT calculation is performed after 1800 seconds.
[0068] In DNS load balancing, if an attacker exploits the fact that certain domain names under some authoritative DNS servers cannot be resolved and do not respond, and maliciously requests these domain names, then the unresponsive NS servers will be penalized. Most of these NS servers will lose their preferred positions, and in extreme cases, only one NS server can provide service for 1800 seconds. This will cause the DNS load balancing to fail, increase the resolution pressure on the link and the corresponding authoritative DNS servers, and greatly increase network latency.
[0069] However, because these attacks that disrupt DNS load balancing typically occur during DNS iterative resolution, they are difficult to detect. They are usually only discovered when DNS load balancing fails, impacting business operations. Therefore, current technologies only detect attacks after they have occurred and caused some impact, relying on manual intervention for protection and blocking, which is untimely and inefficient. How to automatically, promptly, and effectively detect and protect against such attacks has become a pressing issue.
[0070] In view of this, this application provides an attack identification method, apparatus, electronic device, and storage medium. The method involves probing a DNS event message during routine DNS resolution, generating a probe DNS request, and sending the probe DNS request to the NS server. The DNS event message is generated by the DNS resolver when it determines that the NS server has not responded to the original DNS request. The original DNS request includes the requested domain name. Then, based on the NS server's response status to the probe DNS request, the probe result is determined. The probe result indicates whether the NS server's resolution service is faulty and whether the requested domain name has attack characteristics. Thus, by using NS request type re-probing technology, it is possible to determine whether the NS server is faulty and whether the requested domain name has attack characteristics. Without affecting normal business operations, it further discovers hidden attack behaviors in the DNS resolution process, effectively detects attacks, and provides effective protection, ensuring the effectiveness of load balancing. It features attack detection, attack characteristic identification, alarm provision, and automatic generation of protection rules, achieving coordinated protection of the DNS resolver, DNS management platform, and DNS caching server.
[0071] See Figure 1 The diagram shown illustrates a possible application scenario in this application embodiment. This application scenario diagram includes a client 110, a DNS management platform 120, a DNS caching server 130, a DNS resolution server 140, a probe routine 150, and an NS server 160.
[0072] Client 110 is used to send DNS requests.
[0073] The DNS management platform 120 is used to issue alerts and, based on the alert information, generate a list of domain names and a list of IP addresses, which are then distributed in batches to the DNS caching server.
[0074] DNS caching server 130 uses an unencrypted hash algorithm to store domain names and IP addresses in a domain name blacklist and an IP address blacklist, respectively. When a user makes a request, the request data is parsed, and the DNS caching server intercepts and blocks attacks to ensure the stable operation of upstream DNS services.
[0075] DNS resolver 140 is used to resolve DNS requests sent by clients. When a cache miss occurs, it obtains the NS server address for iterative lookup. It is also used to request a DNS event message from the event database, fill in the corresponding message content, and call the probe routine corresponding to the identifier of the DNS event message when it is determined that the NS server has not responded to the original DNS request. The probe routine is placed in a waiting queue and scheduled for execution by the central processing unit (CPU). It is also used to manage the address data of the NS server.
[0076] The detection routine 150 is used to detect whether the DNS server's DNS resolution service is malfunctioning, whether the requested domain name has attack characteristics, and whether the client has botnet characteristics.
[0077] NS server 160 resolves the requested domain name to an IP address.
[0078] The attack identification method provided by the exemplary embodiments of this application will be described below with reference to the accompanying drawings and the application scenarios described above. It should be noted that the application scenarios described above are only shown to facilitate understanding of the spirit and principles of this application, and the embodiments of this application are not limited in any way in this respect.
[0079] See Figure 2 The diagram shown is a flowchart of an attack identification method provided in this application. The specific implementation process of the method is as follows:
[0080] Step 20: The probe routine resolves the DNS event message, generates a probe DNS request, and sends the probe DNS request to the NS server.
[0081] The DNS event message is generated by the DNS resolver when it determines that the NS server has not responded to the original DNS request. The original DNS request contains the requested domain name, and the DNS event message contains the requested domain name and the NS request type. The NS server provides services for the NS request type.
[0082] In this embodiment, the DNS system pre-creates a data resource pool. The data resource pool includes a DNS event database and a probe routine library. The DNS event database is used to store DNS event messages, each containing a unique event ID. The probe routine library is a set of routines that perform re-probing and alarm push for DNS events when DNS resolution times out.
[0083] The detection routines and event messages are matched one-to-one.
[0084] In this embodiment, when the DNS resolver receives a resolution request, if the local cache does not contain a record of the requested domain name carried in the resolution request, it needs to obtain the NS server address for iterative querying. During the iterative query process, the DNS resolver randomly initializes the first RTT (SRTT) of all NS addresses, and then initiates an original DNS request to the NS server of the selected NS address.
[0085] The random initialization value ranges from 1 to 32 μs, which is much smaller than the normal network RTT, ensuring that each NS address has a chance to be selected.
[0086] In this embodiment of the application, if the NS server of the selected NS address does not respond, the DNS resolver requests an event message from the DNS event database, fills in the specific content of the event message, and at the same time, retrieves the corresponding probe routine from the probe routine library through the identifier of the event message, and puts the probe routine into the waiting queue for CPU scheduling and execution.
[0087] The event message includes information such as user address, request domain name, request type, NS server name, NS address, and asynchronous callback interface. The comparison in this embodiment is not limited.
[0088] For example, the format of an event message is as follows:
[0089] Event message format:
[0090] {
[0091] "user_ip":"1.1.1.1",
[0092] "qname": www.test.com ,
[0093] "qtype":"A",
[0094] "ns_name":"ns.test.com",
[0095] "ns_ip":"2.2.2.2",
[0096] "callback":"timeout_process"
[0097] }
[0098] In this embodiment of the application, after the DNS resolver sends the event message, due to the NS address resolution timeout, it needs to penalize the RTT in the NS address data and store this value in the second RTT (NRTT). The NS address data structure stores two RTTs (first RTT and second RTT). The NS address is set to the CHECK state. In this state, the NS is unavailable. The DNS resolver selects another NS address according to the process to continue the subsequent process.
[0099] The smaller the initial RTT, the greater the penalty, which can be reduced by up to 1 second. The first RTT is the preferred RTT, and the second RTT is the newly calculated RTT.
[0100] In this embodiment of the application, the probe routine parses the DNS event message, obtains the content of the DNS event message, encapsulates the probe DNS request data packet using the request domain name and NS request type, sends the probe DNS request to the NS server, and starts a timer.
[0101] Step 21: Determine the probe result based on the NS server's response status to the probe DNS request.
[0102] The detection results indicate whether the NS server's DNS resolution service is malfunctioning and whether the requested domain name has attack characteristics.
[0103] Optionally, in this embodiment of the application, a possible implementation is provided for determining the probe result based on the NS server's response status to the probe DNS request, specifically by performing the following operations:
[0104] Step 210: Determine whether no response to the DNS probe request has been received from the NS server under the preset first response condition. If yes, proceed to step 211; otherwise, proceed to step 212.
[0105] The first response condition consists of the timeout period and the number of retransmissions.
[0106] For example, the timeout period is set to 200 milliseconds and the number of retransmissions is set to 3. If no response is received from the NS server within the timeout period, a retransmission will be performed, with a maximum of 3 retransmissions.
[0107] Step 211: Determine that the NS server's DNS resolution service is faulty and that the requested domain name does not exhibit any attack characteristics.
[0108] In this embodiment of the application, when no response to the DNS probe request is received from the NS server under the preset first response condition, it is determined that the NS server's resolution service is faulty and the requested domain name does not have attack characteristics.
[0109] Furthermore, in this embodiment of the application, after determining that the NS server's resolution service is faulty and the requested domain name does not have attack characteristics, the probe routine sends the probe result to the DNS resolver. Then, the DNS resolver uses the name and NS address of the NS server to query the address data of the NS address from the local cache, replaces the value of the first round-trip time (RTT) contained in the address data with the value of the second RTT, sets the value of the second RTT to 0, sets the status to BYPASS, and re-enters the load balancing algorithm of the preferred strategy for scheduling.
[0110] The probe routine calls the asynchronous callback interface in the DNS event message to send the probe results to the DNS resolver.
[0111] In this way, the NS servers with resolution service failures can be accurately detected, and real penalties can be imposed on the detected NS addresses, ensuring the effectiveness of DNS load balancing.
[0112] Step 212: Determine that the NS server's DNS resolution service is normal, and send a raw DNS request to the NS server. Based on the NS server's response status to the raw DNS request, determine whether the requested domain name has attack characteristics.
[0113] In this embodiment of the application, when the response of the NS server to the probe DNS request is received under the first response condition, it is determined that the resolution service of the NS server is normal, and the request data packet is re-encapsulated using the request domain name and request type in the original request, and the original DNS request is sent to the NS server. Based on the response status of the NS server to the original DNS request, it is determined whether the request domain name has attack characteristics.
[0114] Optionally, in this embodiment of the application, a possible implementation is provided for determining whether a requested domain name has attack characteristics based on the response status of the NS server to the original DNS request, specifically by performing the following operations:
[0115] Step 2120: Determine whether a response to the original DNS request has not been received from the NS server under the preset second response condition. If yes, proceed to step 2121; otherwise, proceed to step 2122.
[0116] The second response condition consists of the timeout period and the number of retransmissions.
[0117] For example, the timeout period is set to 200 milliseconds and the number of retransmissions is set to 3. If no response is received from the NS server within the timeout period, a retransmission will be performed, with a maximum of 3 retransmissions.
[0118] Step 2121: Determine if the requested domain name has attack characteristics.
[0119] In this embodiment, if no response is received from the NS server for the original DNS request under the preset second response condition, it is determined that the NS server's resolution service is normal, but it does not provide service for the requested domain name, meaning the requested domain name has attack characteristics. Since the NS address is penalized at this time, it will not be preferred for a period of time and may be exploited by hackers to launch attacks that cause the DNS load balancing algorithm to fail. Therefore, it can be concluded that the requested domain name has attack characteristics at this time.
[0120] In this way, by sending the original request packet to re-probe the NS server, it is possible to accurately determine whether the requested domain name has attack characteristics when the NS server's DNS resolution service is normal.
[0121] Furthermore, in this embodiment of the application, after determining that the NS server's resolution service is normal and the requested domain name has attack characteristics, the probe routine sends the probe result to the DNS resolver. Then, the DNS resolver uses the name and NS address of the NS server to query the address data of the NS address from the local cache, sets the value of the second RTT contained in the address data to 0, sets the status to BYPASS, does not change the value of the first RTT, and re-enters the load balancing algorithm of the preferred strategy for scheduling.
[0122] The probe routine calls the asynchronous callback interface in the DNS event message to send the probe results to the DNS resolver.
[0123] In this way, the request domains that are attacking him can be accurately detected, and no real penalties are imposed on the NS address, thus ensuring the effectiveness of DNS load balancing.
[0124] Step 2121: Determine that the requested domain name does not have any attack characteristics.
[0125] In this embodiment of the application, when the NS server responds to the original DNS request under the second response condition, it is determined that the requested domain name does not have attack characteristics.
[0126] Furthermore, in this embodiment of the application, after determining the detection result, source tracing detection can be performed on the client to accurately detect whether the client is a botnet. In this embodiment of the application, a possible implementation method for source tracing detection of the client is provided, specifically by performing the following operations:
[0127] Step 22: When the detection results indicate that the requested domain name has attack characteristics, construct a DNS response packet and send the DNS response packet to the client.
[0128] The DNS response packet uses the User Datagram Protocol (UDP), and the TC flag bit of the DNS response packet is set to 1.
[0129] In this embodiment of the application, when constructing the DNS response packet, the TC flag bit in the flags field of the DNS message header is set to 1, and the answer_count part is set to 0.
[0130] Step 23: Determine whether the target DNS request returned by the client has been received. If yes, proceed to step 24; otherwise, proceed to step 25.
[0131] The target DNS request uses the Transmission Control Protocol (TCP).
[0132] Step 24: Determine if the client is a legitimate user.
[0133] In this embodiment of the application, if a target DNS request is received from the client, it is determined that the client is a normal user.
[0134] Step 25: Determine if the client exhibits characteristics of a botnet.
[0135] In this embodiment of the application, if no target DNS request is received from the client, it is determined that the client has the characteristics of a botnet.
[0136] Furthermore, in this embodiment of the application, the detection routine can also encapsulate the requested domain name or the requested domain name + IP address into an alarm message and send the alarm information to the DNS management platform, so that the DNS management platform can issue an alarm and generate a domain name list and an IP address list based on the alarm information, and send them to the DNS cache server in batches, so that the DNS cache server can generate a domain name blacklist and an IP address blacklist based on the domain name list and the IP address list.
[0137] Optionally, in this embodiment of the application, the resources used by event messages and probe routines in the data resource pool are reclaimed.
[0138] The alarm information may include the requested domain name, or the alarm information may include the requested domain name and the client's IP address.
[0139] For example, the format of an alarm message is as follows:
[0140] {
[0141] "data_id":1,
[0142] "access_token":"",
[0143] "target":"2.2.2.2",
[0144] "data":{
[0145] "user_ip":"1.1.1.1",
[0146] "query_name":"alert.com",
[0147] "location":"",
[0148] "event_type":"ns_timeout",
[0149] "alert_msg":"this is alert msg type"
[0150] },
[0151] "timestamp":1661320521493
[0152] }
[0153] In this embodiment of the application, after receiving the alarm information, the DNS management platform will send an alarm to the operation and maintenance personnel, and will identify and parse the alarm message content, generate a list of domain names and a list of IP addresses, and send them to the DNS cache server in batches.
[0154] The alarm types include: on-site monitoring page alarms, SMS and email notifications, etc. When the alarm message contains a requested domain name, a domain name list is generated and sent to the DNS cache server in batches; when the alarm message contains the client's IP address, an IP address list is generated and sent to the DNS cache server in batches.
[0155] In this embodiment of the application, after receiving the domain name list and IP address list issued by the DNS management platform, the DNS caching server generates a domain name blacklist and an IP address blacklist.
[0156] The DNS caching server uses an unencrypted hash algorithm to store the requested domain name and IP address in the domain name blacklist and IP address blacklist, respectively.
[0157] In this way, domain name blacklists and IP address blacklists are generated, and security protection policies are automatically set on the DNS caching server side. When a user makes a request, the request data is parsed out, and attacks can be intercepted and blocked on the DNS caching server. Interception or rate limiting is performed at the network entry point to ensure the stable operation of upstream DNS services.
[0158] In this embodiment, when a user makes a request, the DNS caching server first parses the DNS request data, concatenating the requested domain name and IP address into a 256-bit string. Then, based on the length of the hash bucket, for example, M, it slides a window of logM bits across the 256-bit string to find the interval with the largest number of dissimilarities. This interval is then used as the modulo interval, thus distributing the DNS data stream evenly across the hash buckets. Simultaneously, to avoid performance degradation caused by excessively long collision chains, a two-level nested hash data organization method is adopted. That is, the same hash function is used in each hash bucket to create a second-level hash table, greatly reducing the performance loss caused by hash collisions.
[0159] This allows for better handling of uneven data distribution, avoidance of hotspots, and ensures that data streams are more evenly distributed across multiple hash buckets.
[0160] Based on the same inventive concept, this application also provides an attack detection device, see reference. Figure 3 The diagram shown is a structural schematic of the attack identification device in an embodiment of this application, specifically including:
[0161] The first processing module 301 is used to detect the DNS event message in the probe routine, generate a probe DNS request, and send the probe DNS request to the NS server. The DNS event message is generated by the DNS resolver when it determines that the NS server does not respond to the original DNS request. The original DNS request contains the requested domain name, and the DNS event message contains the requested domain name and the NS request type.
[0162] The detection module 302 is used to determine the detection results based on the response status of the NS server to the DNS detection request. The detection results indicate whether the NS server's resolution service is faulty and whether the requested domain name has attack characteristics.
[0163] In one possible embodiment, when determining the probe result based on the NS server's response status to the probe DNS request, the probe module 302 is further configured to:
[0164] If no response is received from the NS server for the DNS probe request under the preset first response condition, it is determined that the NS server's resolution service is faulty and the requested domain name does not have attack characteristics.
[0165] When the NS server responds to the probing DNS request under the first response condition, it is determined that the NS server's resolution service is normal, and the original DNS request is sent to the NS server. Based on the NS server's response status to the original DNS request, it is determined whether the requested domain name has attack characteristics.
[0166] In one possible embodiment, when determining whether the requested domain name has attack characteristics based on the NS server's response status to the original DNS request, the detection module 302 is further configured to:
[0167] If no response to the original DNS request is received from the NS server under the preset second response condition, it is determined that the requested domain name has attack characteristics;
[0168] When the second response condition is met, and the NS server's response to the original DNS request is received, it is determined that the requested domain name does not exhibit any attack characteristics.
[0169] In one possible embodiment, after determining the probe result based on the NS server's response status to the probe DNS request, a second processing module 303 is further included. The second processing module 303 is used for:
[0170] Send probe results to the DNS resolver so that when the probe results indicate that the NS server's resolution service is faulty, the DNS resolver replaces the value of the first round-trip time (RTT) in the address data with the value of the second RTT and sets the value of the second RTT to 0; and when the probe results indicate that the NS server's resolution service is normal and the requested domain name has attack characteristics, the DNS resolver does not change the value of the first RTT in the address data and sets the value of the second RTT to 0.
[0171] The first RTT is the preferred RTT, and the second RTT is the newly calculated RTT.
[0172] In one possible embodiment, after determining the probe result based on the NS server's response status to the probe DNS request, a tracing module 304 is further included. The tracing module 304 is used for:
[0173] When the detection results indicate that the requested domain name has attack characteristics, a DNS response packet is constructed and sent to the client. The DNS response packet uses the User Datagram Protocol (UDP) and the TC flag bit of the DNS response packet is set to 1.
[0174] If a target DNS request is received from the client, it is determined that the client is a legitimate user. The target DNS request uses the Transmission Control Protocol (TCP).
[0175] If no target DNS request is received from the client, the client is determined to have characteristics of a botnet.
[0176] In one possible embodiment, the apparatus further includes a third processing module 305, which is configured to:
[0177] Send alarm information to the DNS management platform to trigger an alert. Based on the alarm information, generate a list of domain names and a list of IP addresses, and distribute them in batches to the DNS cache server. The DNS cache server then generates a domain name blacklist and an IP address blacklist based on the domain name and IP address lists.
[0178] The alarm information may include the requested domain name, or the alarm information may include the requested domain name and the client's IP address.
[0179] Based on the above embodiments, see Figure 4 The diagram shown is a structural schematic of the electronic device in an embodiment of this application.
[0180] This application provides an electronic device that may include a processor 410 (Center Processing Unit, CPU), a memory 420, an input device 430, and an output device 440. The input device 430 may include a keyboard, a mouse, a touch screen, etc., and the output device 440 may include a display device, such as a liquid crystal display (LCD) or a cathode ray tube (CRT).
[0181] The memory 420 may include read-only memory (ROM) and random access memory (RAM), and provides the processor 410 with program instructions and data stored in the memory 420. In this embodiment, the memory 420 may be used to store the program of any attack identification method in this embodiment.
[0182] The processor 410 executes any of the attack identification methods in the embodiments of this application according to the program instructions stored in the memory 420.
[0183] Based on the above embodiments, this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the attack identification method in any of the above method embodiments.
[0184] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0185] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0186] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0187] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0188] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.
Claims
1. An attack identification method, characterized in that, include: The probe routine resolves DNS event messages, generates a probe DNS request, and sends the probe DNS request to the NS server. The DNS event message is generated by the DNS resolver when it determines that the NS server does not respond to the original DNS request. The original DNS request includes the requested domain name, and the DNS event message includes the requested domain name and the NS request type. If no response is received from the NS server for the DNS probe request under the preset first response condition, it is determined that the NS server's DNS resolution service is faulty and the requested domain name does not have attack characteristics. When the response from the NS server to the probe DNS request is received under the first response condition, it is determined that the resolution service of the NS server is normal, and the original DNS request is sent to the NS server. Based on the response status of the NS server to the original DNS request, the probe result is determined. The probe result indicates whether the resolution service of the NS server is faulty and whether the requested domain name has attack characteristics. The probe result is sent to the DNS resolver so that when the probe result indicates that the NS server's resolution service is faulty, the DNS resolver replaces the value of the first round-trip time (RTT) in the address data with the value of the second RTT and sets the value of the second RTT to 0; and when the probe result indicates that the NS server's resolution service is normal and the requested domain name has attack characteristics, the DNS resolver does not change the value of the first RTT in the address data and sets the value of the second RTT to 0. Wherein, the first RTT is the preferred RTT, and the second RTT is the newly calculated RTT.
2. The method as described in claim 1, characterized in that, The step of determining whether the requested domain name has attack characteristics based on the response status of the NS server to the original DNS request includes: If no response is received from the NS server for the original DNS request under the preset second response condition, it is determined that the requested domain name has attack characteristics; When the NS server receives a response to the original DNS request under the second response condition, it is determined that the requested domain name does not have attack characteristics.
3. The method as described in claim 1, characterized in that, After determining the probe result based on the NS server's response status to the probe DNS request, the process further includes: When the detection result indicates that the requested domain name has attack characteristics, a DNS response packet is constructed and sent to the client, wherein the DNS response packet uses User Datagram Protocol (UDP) and the TC flag bit of the DNS response packet is 1; If a target DNS request is received from the client, it is determined that the client is a normal user, wherein the target DNS request uses the Transmission Control Protocol (TCP). If the target DNS request is not received from the client, then the client is determined to have the characteristics of a botnet.
4. The method as described in claim 3, characterized in that, The method further includes: Send alarm information to the DNS management platform to trigger an alarm, and generate a domain name list and an IP address list based on the alarm information. Then, send these lists to the DNS cache server in batches, so that the DNS cache server can generate a domain name blacklist and an IP address blacklist based on the domain name list and the IP address list. The alarm information may include the requested domain name, or the alarm information may include the requested domain name and the client's IP address.
5. An attack detection device, characterized in that, include: The first processing module is used to detect the DNS event message of the routine, generate a probe DNS request, and send the probe DNS request to the NS server. The DNS event message is generated by the DNS resolver when it determines that the NS server does not respond to the original DNS request. The original DNS request includes: the requested domain name, and the DNS event message includes: the requested domain name and the NS request type. The detection module is configured to: when no response is received from the NS server for the detection DNS request under a preset first response condition, determine that the NS server's DNS resolution service is faulty and that the requested domain name does not exhibit attack characteristics; when a response is received from the NS server for the detection DNS request under the first response condition, determine that the NS server's DNS resolution service is normal, and send the original DNS request to the NS server; and based on the NS server's response status to the original DNS request, determine the detection result and send the detection result to the DNS resolver, so that when the detection result indicates that the NS server's DNS resolution service is faulty, the DNS resolver replaces the value of the first round-trip time (RTT) in the address data with the value of the second RTT and sets the value of the second RTT to 0; and when the detection result indicates that the NS server's DNS resolution service is normal and the requested domain name exhibits attack characteristics, it does not change the value of the first RTT in the address data and sets the value of the second RTT to 0; wherein, the first RTT is the preferred RTT, and the second RTT is a newly calculated RTT; the detection result indicates whether the NS server's DNS resolution service is faulty and whether the requested domain name exhibits attack characteristics.
6. The apparatus as claimed in claim 5, characterized in that, When determining the probe result based on the NS server's response status to the probe DNS request, the probe module is further configured to: If no response is received from the NS server for the DNS probe request under the preset first response condition, it is determined that the NS server's DNS resolution service is faulty and the requested domain name does not have attack characteristics. When the response to the probe DNS request is received from the NS server under the first response condition, it is determined that the resolution service of the NS server is normal, and the original DNS request is sent to the NS server. Based on the response status of the NS server to the original DNS request, it is determined whether the requested domain name has attack characteristics.
7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method according to any one of claims 1 to 4.
8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 4.
Citation Information
Patent Citations
SAE gateway fault processing method and system
CN113497727A
Domain name server security detection method and device, electronic equipment and storage medium
CN116684110A