WO2017004947A1 - 防止域名劫持的方法和装置 - Google Patents

防止域名劫持的方法和装置 Download PDF

Info

Publication number
WO2017004947A1
WO2017004947A1 PCT/CN2015/098224 CN2015098224W WO2017004947A1 WO 2017004947 A1 WO2017004947 A1 WO 2017004947A1 CN 2015098224 W CN2015098224 W CN 2015098224W WO 2017004947 A1 WO2017004947 A1 WO 2017004947A1
Authority
WO
WIPO (PCT)
Prior art keywords
dns
list
correspondence information
hijacked
address
Prior art date
Application number
PCT/CN2015/098224
Other languages
English (en)
French (fr)
Inventor
蒋嘉琦
叶爱平
陈鑫
韩龙
Original Assignee
安一恒通（北京）科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 安一恒通（北京）科技有限公司 filed Critical 安一恒通（北京）科技有限公司
Publication of WO2017004947A1 publication Critical patent/WO2017004947A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks

Definitions

  • the present application relates to the field of communications technologies, and in particular, to the field of communication information security technologies, and in particular, to a method and apparatus for preventing domain name hijacking.
  • Domain Name System DNS hijacking refers to intercepting the request for domain name resolution within the hijacked network, analyzing the requested domain name, releasing the request for the domain name outside the hijacking range, returning the fake IP address for the request within the scope of the hijacking domain, or nothing. Doing a response to the request is such that a fake web address is not responsive or accessible to a particular network.
  • the user may be prompted to modify the local DNS configuration through a pop-up window, and then the host's DNS configuration is modified to achieve the purpose of repairing the hijacked DNS. .
  • this technique of repairing the hijacked DNS has no use for DNS hijacking by an illegal operator or an illegal user on a domain name server or a network transport node, and the user cannot access the DNS besides the prompt that the DNS is hijacked. Internet service.
  • the present application provides a method and apparatus for preventing domain name hijacking.
  • the present application provides a method for preventing domain name hijacking, including:
  • the present application provides an apparatus for preventing domain name hijacking, including:
  • a crawling unit configured to capture a network data packet of the host
  • An extracting unit configured to extract, from the network data packet, correspondence information between a domain name and an IP address
  • a determining unit configured to determine, according to the extracted correspondence information, whether the DNS of the domain name system is hijacked
  • a modifying unit configured to modify the IP address to an acknowledged IP address in response to the DNS being hijacked
  • the first release unit releases the network packet after modifying the IP address.
  • the method and device for preventing domain name hijacking provided by the present application firstly extract the correspondence relationship between the domain name and the IP address from the network data packet of the captured host, and then determine whether the DNS is hijacked, and the IP address of the hijacked DNS. After being modified to the confirmed IP address and released, the accuracy and success rate of the host accessing the network are improved, and the reliability and security of the host accessing the network are improved.
  • FIG. 1 illustrates an exemplary system architecture to which embodiments of the present application may be applied
  • FIG. 2 illustrates an exemplary flow chart of a method of preventing domain name hijacking in accordance with one embodiment of the present application
  • FIG. 3 illustrates an exemplary flowchart of a method of determining whether a DNS is hijacked according to an embodiment of the present application
  • FIG. 4 illustrates an exemplary flowchart of a method of determining whether a DNS is hijacked according to another embodiment of the present application
  • FIG. 5 illustrates a structure of an apparatus for preventing domain name hijacking according to an embodiment of the present application.
  • FIG. 6 is a schematic structural diagram of a determining unit according to an embodiment of the present application.
  • FIG. 7 is a schematic diagram showing an application scenario of an apparatus for preventing domain name hijacking according to an embodiment of the present application.
  • FIG. 8 is a block diagram showing the structure of a computer system suitable for implementing a client device or server of an embodiment of the present application.
  • FIG. 1 illustrates an exemplary system architecture in which embodiments of the present application may be applied.
  • system architecture 100 can include client devices 101, 102, network 103, and server 104.
  • Network 103 is used to provide a medium for communication links between client devices 101, 102 and server 104.
  • Network 103 may include various types of connections, such as wired, wireless communication links, fiber optic cables, and the like.
  • User 110 can interact with server 104 over network 103 using client devices 101, 102 to receive or send messages and the like.
  • Various network service applications such as browser services, search engines, social platform software, etc., can be installed on the client devices 101, 102.
  • Client devices 101, 102 can be a variety of electronic devices including, but not limited to, personal computers, smart phones, smart watches, tablets, personal digital assistants, and the like.
  • the server 104 may be a server that provides various services, such as a domain name server, a cloud server that provides data query analysis services, and a network node server that transmits and receives network data packets of clients on a network transmission path.
  • the server can store, analyze, and the like the received data, and feed back the processing result to the client device.
  • the method for preventing domain name hijacking may be Executed by the client device 101, 102, may also be performed by the network node server, may also be performed by the client device 101, 102 or one of the network node servers in cooperation with the cloud server; the device for preventing domain name hijacking may be set on the client device 101, 102, may also be set in the network node server, may also be partially disposed in the client device 101, 102 or network node server, and the other portion is set in the cloud server.
  • determining whether DNS hijacking occurs may be performed in the cloud server based on the correspondence information between the extracted domain name and the IP address.
  • the client device 101, 102 or the network node server may send the corresponding relationship information between the extracted domain name and the IP address.
  • the cloud server judges the correspondence information between the extracted domain name and the IP address according to the cloud list, and returns the judgment result of whether the DNS is hijacked to the client 101, 102 or the network node server; if there is no network or network 103,
  • the information of the corresponding relationship between the extracted domain name and the IP address may be determined by the client device 101, 102 or the network node server according to the local list.
  • FIG. 2 shows an exemplary flowchart of a method for preventing domain name hijacking according to an embodiment of the present application.
  • the method for preventing domain name hijacking may include:
  • step S201 the network packet of the host is captured.
  • the network data packet of the host refers to a data packet that is sent or received by the host and communicates with other hosts or servers, including the domain name and its corresponding IP address.
  • DNS response packets and/or Hypertext Transfer Protocol HTTP request packets are examples of hosts or servers.
  • step S202 correspondence information between the domain name and the IP address is extracted from the network packet.
  • the correspondence between the domain name and the IP address is extracted from the network data packet of the captured host, that is, the domain name specified by the data packet and the IP address corresponding to the domain name are captured from the network data packet.
  • step S203 the domain name system is determined based on the extracted correspondence information. Whether the DNS is hijacked.
  • the DNS of the domain name system is hijacked, and may be determined by using a pre-established domain name and a corresponding database of the correct IP address. If the correspondence information exists in the corresponding database, the DNS Not hijacked, if the correspondence information does not exist in the corresponding database, the DNS is hijacked.
  • step S204 in response to the DNS being hijacked, the IP address is modified to the confirmed IP address.
  • the IP address can be modified to the confirmed IP address.
  • the confirmed IP address is obtained according to the confirmed correspondence list of the domain name and the IP address.
  • the confirmed correspondence list may be a representation of the corresponding database described above.
  • step S205 the network packet after the IP address is modified is released.
  • the network data packet after the IP address is modified may be released.
  • the above steps of the method for preventing domain name hijacking can be completed by the client. For example, after the client captures the network data packet of the local machine, the client may perform an operation of extracting the domain name and its corresponding IP address, and then performing an operation of determining whether a DNS hijacking occurs, and then performing an operation of modifying the IP address if a DNS hijacking occurs. Then, the operation of releasing the data packet after the IP address is modified is performed.
  • the above steps of the method for preventing domain name hijacking may also be performed by a network node server on the client network transmission path.
  • the network node server may perform an operation of extracting the domain name and its corresponding IP address after the network packet of the host is captured, and then performing an operation of determining whether a DNS hijacking occurs, and then performing an operation of modifying the IP address if a DNS hijacking occurs. Then, the operation of releasing the data packet after the IP address is modified is performed.
  • the steps of the above method for preventing domain name hijacking may also be partially completed by the client, and partially by the cloud server.
  • the client can capture the network data packet of the local device, and then perform the operation of extracting the domain name and its corresponding IP address, and then sending the extracted domain name and its corresponding IP address to the cloud server, which is executed by the cloud server.
  • the IP address corresponding to the extracted domain name is returned to the client, and the client performs an operation of modifying the IP address, and performs the operation of releasing the data packet after modifying the IP address.
  • the method for preventing domain name hijacking may further include: releasing the network data packet in response to the DNS being not hijacked.
  • the method for preventing domain name hijacking in the above embodiment of the present application first extracts the correspondence relationship between the domain name and the IP address from the network data packet of the captured host, and then determines whether the DNS is hijacked, and the IP address of the hijacked DNS. After being modified to the confirmed IP address, the user can access the network normally, which improves the reliability and security of the client accessing the network. In some implementations, if the DNS is not hijacked, the captured network data packets are released, thereby improving the efficiency of the host accessing the network.
  • FIG. 3 an exemplary flowchart of a method of determining whether a DNS is hijacked, that is, a flowchart showing one implementation of step 203 above, is illustrated in accordance with an embodiment of the present application.
  • step 301 it is checked whether the extracted correspondence information exists in the confirmed correspondence list.
  • the confirmed correspondence list may include a plurality of confirmed correspondence information, and the confirmed correspondence information includes the domain name and its corresponding IP address.
  • the same domain name can correspond to one or more confirmed IP addresses.
  • the confirmed correspondence information may be obtained according to the network access data statistics, or may be obtained according to the preset confirmed correspondence information.
  • the storage location of the confirmed correspondence list may be located in one or more of the following locations: a client, a network node server on the client network transmission path, and a cloud server.
  • the domain name may be used as a keyword to search whether the extracted IP address includes the extracted IP address, and if so, the extracted correspondence information is determined. Exist in the confirmed correspondence list, if not included, it is determined that the extracted correspondence information does not exist in the confirmed correspondence list.
  • the query operation performed on the extracted correspondence information may be Performing on the device storing the confirmed correspondence list, for example, when the confirmed correspondence list is stored in the client or the network node server that extracts the correspondence information, the query operation may be performed in the client or the network node server; When it is confirmed that the correspondence list is stored in the cloud server, the query operation can be performed in the cloud server.
  • step 302 if the correspondence information does not exist in the confirmed correspondence list, it is determined that the DNS is hijacked.
  • the method for determining whether the DNS is hijacked in the above embodiment of the present application determines whether the DNS is hijacked by querying whether the extracted correspondence information exists in the confirmed correspondence list, thereby increasing the accuracy of the judgment and improving the judgment. effectiveness.
  • FIG. 4 an exemplary flowchart of a method of determining whether a DNS is hijacked, that is, a flowchart showing another implementation of step 203 above, is illustrated in accordance with another embodiment of the present application.
  • the confirmed correspondence list of the foregoing embodiment may include a cloud list stored in the cloud server, and may alternatively or additionally include a local list obtained from the cloud list.
  • a local list from the cloud list it can be obtained based on one or more of the following parameters: the geographic location of the client, the ranking of the website traffic, the popularity of the user, the time of the user access, the user's click rate, and the number of pages visited by the user.
  • the geographic location of the client may be determined according to the IP address of the client, and the common domain name and its corresponding IP address are returned according to the geographic location (if the IP address is more, It is possible to return only the preset number of IP addresses at the top of the IP address list).
  • a method 400 of determining whether a DNS is hijacked includes:
  • Step 401 it is queried whether the corresponding relationship information exists in the local list, and if so, step 402 is performed, and if not, step 403 is performed;
  • step 402 it is determined that the DNS is not hijacked.
  • Step 403 the query whether the extracted correspondence information exists in the local relationship list of the confirmed DNS hijacking, and if so, step 404 is performed; if not, step 405 is performed;
  • step 404 it is determined that the DNS is hijacked.
  • Step 405 Query whether the extracted correspondence information exists in the cloud list, and if so, Then step 406 is performed, and if not, step 408 is performed;
  • Step 406 it is determined that the DNS is not hijacked, and then step 407 may be performed;
  • step 407 the correspondence information is stored in a local list.
  • Step 408 determining that the DNS is hijacked
  • step 409 the correspondence information is stored in the relationship list of the locally confirmed DNS hijacking.
  • the time of the query response may be preset, and if the query response time exceeds the preset At the time, the network data packet can be released; if the corresponding relationship information does not exist in the cloud list after the preset time is exceeded, it is determined that the DNS is hijacked, and the corresponding relationship information is stored to the corresponding relationship of the locally confirmed DNS hijacking. In the list, if the corresponding relationship information exists in the cloud list after the preset time is exceeded, the corresponding relationship information is stored in the local list.
  • FIG. 5 shows a schematic structural diagram of an apparatus for preventing domain name hijacking according to an embodiment of the present application.
  • the apparatus 500 for preventing domain name hijacking may include: a crawling unit 510, an extracting unit 520, a determining unit 530, a modifying unit 540, and a first releasing unit 550.
  • the crawling unit 510 can be configured to capture network data packets of the host.
  • the extracting unit 520 may be configured to extract correspondence information between the domain name and the IP address from the network data packet.
  • the determining unit 530 can be configured to determine whether the domain name system DNS is hijacked based on the extracted correspondence information.
  • Modification unit 540 can be configured to modify the IP address to the confirmed IP address in response to the DNS being hijacked.
  • the first release unit 550 can configure the network data packet after the IP address is modified.
  • the confirmed IP address in the modification unit is derived from the list of confirmed correspondences of the domain name and the IP address.
  • the device 500 for preventing domain name hijacking may further include: a second release unit 560.
  • the second release unit 560 can be configured to release network packets in response to the DNS being unhijacked.
  • the determining unit 530 may include: a query subunit 531 and a determining subunit 532.
  • the query sub-unit 531 can be configured to query whether the extracted correspondence information exists in the confirmed correspondence list.
  • the determining subunit 532 may be configured to determine that the DNS is hijacked if the correspondence information does not exist in the confirmed correspondence list.
  • the confirmed correspondence list may include: a cloud list, and/or a local list obtained from the cloud list based on one or more of the following parameters: a geographic location of the client, a ranking of the website traffic, a user access popularity, User access time, user click rate, and number of user access pages.
  • the determining unit 530 may include (not shown): a local query subunit, configured to query whether the correspondence information exists in the local list.
  • the hijacking query subunit is configured to: in response to the correspondence information not existing in the local list, query whether the correspondence information exists in the relationship list of the locally confirmed DNS hijacking.
  • the first hijacking determining subunit is configured to determine that the DNS is hijacked in response to the correspondence information being present in the relationship list of the locally confirmed DNS hijacking.
  • the determining unit 530 may further include: (not shown): a cloud query subunit, configured to query whether the correspondence information exists in the cloud list in response to the correspondence information not being present in the relationship list of the locally confirmed DNS hijacking .
  • the second hijacking determining subunit is configured to determine that the DNS is hijacked in response to the correspondence information not being present in the cloud list.
  • the cloud list and the local list may be included, and the device 500 for preventing domain name hijacking may further include: an unhijacked determining subunit, configured to exist in the cloud list in response to the corresponding relationship information. And determining that the DNS is not hijacked; and storing subunits for storing the correspondence information to the local list.
  • the device may include the cloud list and the local list, and the device 500 for preventing the domain name hijacking may further include: a third releasing unit, configured to query whether the corresponding relationship information exists in the cloud list. The network packet is released when the time exceeds the preset time.
  • the apparatus 500 for preventing domain name hijacking may further include a third release unit, and the determining unit 530 may further include: a third hijacking determination subunit, configured to query after the preset time is exceeded If the correspondence information does not exist in the cloud list, it is determined that the DNS is hijacked. And the first storage subunit, configured to store the correspondence information in a relationship list of the locally confirmed DNS hijacking.
  • the device 500 may further include: a second storage subunit, configured to: if the query corresponding information exists in the cloud list after the preset time is exceeded, store the correspondence information to the local list.
  • FIG. 7 is a schematic diagram of an application scenario of an apparatus for preventing domain name hijacking according to an embodiment of the present application.
  • the device 700 for preventing domain name hijacking may include a client 710 and a cloud server 720.
  • the fetching unit 510 and the extracting unit 520 in the device 500 for preventing domain name hijacking in FIG. 5 described above may be implemented by the “DNS packet parsing module” 711 and the “HTTP redirection module” 713 in the client 710; the determining unit 530 It may be implemented by a combination of "DNS Security Policy Storage and Query Module” 712 in client 710 and “Cloud Service Module” 721 in cloud server 720; modification unit 540 may be "DNS packet parsing module” 711 and "HTTP redirect” Module 713 is implemented; first release unit 550 can be implemented by "DNS packet parsing module” 711 and “HTTP redirection module” 713 in client 710; second release unit 560 in device 500 can be “DNS packet” The parsing module "711 is implemented.
  • the device 700 for preventing domain name hijacking can prevent domain name hijacking by the following steps:
  • Step 1 When the client starts for the first time, the "DNS security policy storage and query module" 712 obtains a list of IP addresses corresponding to the common website domain name from the "cloud service module” 721, because the domain name corresponds to the IP address in different geographical locations.
  • the address may be different, so the server needs to determine the approximate geographic location of the client based on the IP address of the client, according to its location. The location returns the IP address corresponding to the common domain name (if the IP address is large, only the top N IP addresses are returned).
  • Step 2 The "DNS packet parsing module” 711 attempts to resolve all the DNS response packets sent to the host, and obtain the corresponding relationship between the domain name and the IP address, and according to the correspondence between the resolved domain name and the IP address, "DNS"
  • the security policy storage and query module 712 initiates a query request to determine whether the IP address corresponding to the domain name is legal.
  • Step 3 After obtaining the query request of the "DNS packet parsing module" 711, the "DNS security policy storage and query module” 712 first attempts to perform a query in the local database to determine whether the IP address corresponding to the domain name is in a legal list or If the IP address corresponding to the domain name is in the legal list, the DNS security policy storage and query module 712 notifies the DNS packet parsing module 711 that the original query is valid, and the DNS data is in the DNS list. The packet parsing module 711 can release the DNS reply packet without modification.
  • Step 4 If the IP address corresponding to the domain name is found in the black list in step 3, select an IP address in the legal IP address list corresponding to the domain name and return it to the "DNS packet parsing module" 711, "DNS packet parsing module.” 711, when obtaining a valid IP address, modify the previously obtained DNS response data packet, replace the illegal IP address in the original data packet with a legal IP address, and modify the modified DNS response data packet after the modification. Release.
  • Step 5 If the relationship between the domain name and the IP address is not found in the local database in step 3, the "DNS security policy storage and query module" 712 initiates a cloud query request to the "cloud service module” 721 to query the security of the domain name and the IP address. relationship.
  • Step 6 In step 5, if the cloud query request is within T time (the DNS response packet cannot be blocked for a long time, otherwise it will affect the host system network and user experience, T is a configurable value) response, then "DNS The security policy storage and query module 712 updates the local database-related whitelist (confirmed correspondence information) and the blacklist list according to the result of the cloud query request, and if the cloud query request result is a match, the "DNS packet parsing module" is notified. 711 directly releases the DNS data packet; if the cloud query request result is a mismatch (a DNS hijack may occur), the DNS response packet is modified by using the matching IP notification "DNS packet parsing module" 711 attached to the cloud query request result.
  • Step 7 If the result of the cloud query request fails to be returned in the T time in step 5, the "DNS security policy storage and query module" 712 needs to notify the "DNS packet parsing module” 711 that the current cloud query request times out, "DNS data. The packet parsing module "711 directly releases the DNS response packet without modification.
  • Step 8 In the case of step 7, after the cloud query request result is answered at a certain moment in the future, the "DNS security policy storage and query module" 712 needs to update the local security policy database (whitelist and blacklist) according to the cloud query request result. . If the result of the cloud query request is not matched, the triplet of the domain name, the unmatched IP address, and the matching IP address returned by the cloud query request needs to be added to a table specifically used for the "HTTP redirect module".
  • Step 9 The "HTTP Redirection Module” 713 is responsible for monitoring all HTTP request data packets initiated by the host, analyzing the host domain corresponding to the HTTP header and the IP address to which the HTTP header is sent, and using the dual domain of the domain name + IP address to "DNS security.”
  • the Policy Storage and Query Module 712 initiates a query to determine if the current HTTP request has received a DNS hijacking effect.
  • Step 10 The DNS security policy storage and query module 712, after receiving the query request of the HTTP redirecting module 713, performs a query in the special table in the above step 8 according to the domain name and the IP address, and determines the IP corresponding to the domain name. Whether the address is an unmatched IP address (a DNS hijacking may occur). If the IP address of the current query is found to be an unmatched IP address, the HTTP redirect module 713, HTTP is answered using the matching IP address recorded in the table.
  • the redirection module 713 performs network redirection on the current HTTP data packet according to the obtained IP address, and sends the data packet to the correct and matching IP address, thereby avoiding the "DNS packet parsing module" 711 because the cloud query request timeout may be The problem caused by the failure to prevent DNS hijacking.
  • the units recited in apparatus 500 described above correspond to the various steps in the method described with reference to FIG.
  • the units described in apparatus 600 correspond to the various steps in the method described with reference to FIG.
  • the operations and features described above for the method of preventing DNS hijacking are equally applicable to the apparatus 500 and the units contained therein, and the operations and features described above for the method of determining whether the DNS is hijacked are equally applicable to the apparatus 600 and the inclusion thereof.
  • the unit is not described here.
  • Corresponding units in devices 500 and 600 can cooperate with units in the client device and/or server to implement the solution of the embodiments of the present application.
  • the device for preventing DNS hijacking provided by the foregoing embodiment of the present application can send a data packet to a correct and matching IP address, which can improve the reliability of the client accessing the network.
  • FIG. 8 a block diagram of a computer system 800 suitable for use in implementing a client device or server of an embodiment of the present application is shown.
  • computer system 800 includes a central processing unit (CPU) 801 that can be loaded into a program in random access memory (RAM) 803 according to a program stored in read only memory (ROM) 802 or from storage portion 808. And perform various appropriate actions and processes.
  • RAM random access memory
  • ROM read only memory
  • RAM 803 various programs and data required for the operation of the system 800 are also stored.
  • the CPU 801, the ROM 802, and the RAM 803 are connected to each other through a bus 804.
  • An input/output (I/O) interface 805 is also coupled to bus 804.
  • I/O interface 805 The following components are connected to I/O interface 805: an input portion 806 that includes a keyboard, mouse, and the like.
  • An output portion 807 such as a cathode ray tube (CRT), a liquid crystal display (LCD), or the like, and a speaker or the like is included.
  • a storage portion 808 including a hard disk or the like is included.
  • the communication section 809 performs communication processing via a network such as the Internet.
  • Driver 810 is also coupled to I/O interface 805 as needed.
  • a removable medium 811 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory or the like, is mounted on the drive 810 as needed so that a computer program read therefrom is installed into the storage portion 808 as needed.
  • embodiments of the present disclosure include a computer program product comprising a computer program tangibly embodied on a machine readable medium, the computer program comprising program code for executing the method illustrated in the flowchart.
  • the computer program can be downloaded and installed from the network via communication portion 809, and/or installed from removable media 811.
  • each block of the flowchart or block diagrams can represent a module, a program segment, or a portion of code that includes one or more logic for implementing the specified.
  • Functional executable instructions can also be noted that in some alternative implementations, the functions noted in the blocks may also be presented in a different order than that illustrated in the drawings. Health. For example, two successively represented blocks may in fact be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending upon the functionality involved.
  • each block of the block diagrams and/or flowcharts, and combinations of blocks in the block diagrams and/or flowcharts can be implemented in a dedicated hardware-based system that performs the specified function or operation. Or it can be implemented by a combination of dedicated hardware and computer instructions.
  • the units involved in the embodiments of the present application may be implemented by software or by hardware.
  • the described unit may also be provided in the processor, for example, as a processor including a grabbing unit, an extracting unit, a judging unit, a modifying unit, and a first releasing unit.
  • the names of these units do not constitute a limitation on the unit itself under certain circumstances.
  • the crawl unit may also be described as “a unit for capturing network packets of the host”.
  • the present application also provides a computer readable storage medium, which may be a computer readable storage medium included in the apparatus described in the above embodiments. It may also be a computer readable storage medium that exists alone and is not assembled into the client.
  • the computer readable storage medium stores one or more programs that are used by one or more processors to perform the methods of preventing DNS hijacking as described herein.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请公开了一种防止域名劫持的方法，包括：抓取主机的网络数据包；从所述网络数据包中提取域名与IP地址的对应关系信息；基于提取的对应关系信息，判断域名系统DNS是否被劫持；响应于所述DNS被劫持，将所述IP地址修改为已确认的IP地址；放行修改IP地址后的网络数据包，提高了主机访问网络的准确率和成功率，提升了主机访问网络的可靠性和安全性。

Description

防止域名劫持的方法和装置
相关申请的交叉引用
本申请要求于2015年07月07日提交的中国专利申请号为“201510394124.7”的优先权，其全部内容作为整体并入本申请中。
技术领域
本申请涉及通信技术领域，具体涉及通信信息安全技术领域，尤其涉及防止域名劫持的方法和装置。
背景技术
域名系统DNS劫持是指在劫持的网络范围内拦截域名解析的请求，分析请求的域名，将域名处于劫持范围以外的请求放行，对域名处于劫持范围以内的请求返回假的IP地址或者什么都不做使请求失去响应，使得对于特定的网络不能反应或访问的是假网址。
现有技术中，当判断出当前的主机的DNS被劫持时，可以通过弹窗提示用户修改本机DNS的相关配置，之后通过接收的对主机的DNS配置的修改达到修复被劫持的DNS的目的。
然而，这种修复被劫持的DNS的技术，对于非法运营商或非法用户在域名服务器或网络传输节点进行的DNS劫持没有任何用处，用户除了能够看到DNS被劫持的提示外仍然无法正常的访问网络服务。
发明内容
鉴于现有技术中的上述缺陷或不足，期望能够提供一种可靠性好，安全性高的方案。为了实现上述一个或多个目的，本申请提供了防止域名劫持的方法和装置。
第一方面，本申请提供了一种防止域名劫持的方法，包括：
抓取主机的网络数据包；
从所述网络数据包中提取域名与IP地址的对应关系信息；
基于提取的对应关系信息，判断域名系统DNS是否被劫持；
响应于所述DNS被劫持，将所述IP地址修改为已确认的IP地址；
放行修改IP地址后的网络数据包。
第二方面，本申请提供了一种防止域名劫持的装置，包括：
抓取单元，用于抓取主机的网络数据包；
提取单元，用于从所述网络数据包中，提取域名与IP地址的对应关系信息；
判断单元，用于基于提取的对应关系信息，判断域名系统DNS是否被劫持；
修改单元，用于响应于所述DNS被劫持，将所述IP地址修改为已确认的IP地址；
第一放行单元，放行修改IP地址后的网络数据包。
本申请提供的防止域名劫持的方法和装置，首先从抓取的主机的网络数据包中提取域名与IP地址的对应关系信息，之后判断DNS是否被劫持，对于被劫持的DNS，将其IP地址修改为已确认的IP地址后放行，提高了主机访问网络的准确率和成功率，提升了主机访问网络的可靠性和安全性。
附图说明
通过阅读参照以下附图所作的对非限制性实施例的详细描述，本申请的其它特征、目的和优点将会变得更明显：
图1示出了可以应用本申请实施例的示例性系统架构；
图2示出了根据本申请一个实施例的防止域名劫持的方法的示例性流程图；
图3示出了根据本申请一个实施例的判断DNS是否被劫持的方法的示例性流程图；
图4示出了根据本申请另一个实施例的判断DNS是否被劫持的方法的示例性流程图；
图5示出了根据本申请一个实施例的防止域名劫持的装置的结构 示意图；
图6示出了根据本申请一个实施例的判断单元的结构示意图；
图7示出了根据本申请一个实施例的防止域名劫持的装置的应用场景的示意图；
图8示出了适于用来实现本申请实施例的客户端设备或服务器的计算机系统的结构示意图。
具体实施方式
下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。
需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。
图1示出了可以应用本申请实施例的示例性系统架构。
如图1所示，系统架构100可以包括客户端设备101、102、网络103和服务器104。网络103用以在客户端设备101、102和服务器104之间提供通信链路的介质。网络103可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
用户110可以使用客户端设备101、102通过网络103与服务器104交互，以接收或发送消息等。客户端设备101、102上可以安装有各种网络服务应用，例如浏览器服务、搜索引擎、社交平台软件等。
客户端设备101、102可以是各种电子设备，包括但不限于个人电脑、智能手机、智能手表、平板电脑、个人数字助理等等。
服务器104可以是提供各种服务的服务器，例如域名服务器、提供数据查询分析服务的云端服务器以及网络传输路径上收发客户端的网络数据包的网络节点服务器。服务器可以对接收到的数据进行存储、分析等处理，并将处理结果反馈给客户端设备。
需要说明的是，本申请实施例所提供的防止域名劫持的方法可以 由客户端设备101、102执行，也可以由网络节点服务器执行，还可以由客户端设备101、102或网络节点服务器之一配合云端服务器执行；防止域名劫持的装置可以设置于客户端设备101、102中，也可以设置于网络节点服务器中，还可以一部分设置于客户端设备101、102或网络节点服务器中，另一部分设置于云端服务器中。在一些实施例中，基于提取的域名与IP地址的对应关系信息判断是否发生DNS劫持可以在云端服务器中进行。例如，在基于提取的域名与IP地址的对应关系信息进行判断是否发生DNS劫持时，如果网络103通畅，客户端设备101、102或网络节点服务器可以将提取的域名与IP地址的对应关系信息发送给云端服务器，由云端服务器根据云端列表对提取的域名与IP地址的对应关系信息进行判断，返回DNS是否被劫持的判断结果给客户端101、102或网络节点服务器；如果没有网络或网络103不畅通，可以由客户端设备101、102或网络节点服务器根据本地列表对提取的域名与IP地址的对应关系信息进行判断。
应该理解，图1中的客户端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的客户端设备、网络和服务器。
请参考图2，其示出了根据本申请一个实施例的防止域名劫持的方法的示例性流程图。
如图2所示，防止域名劫持的方法可以包括：
首先，在步骤S201中，抓取主机的网络数据包。
在本实施例中，主机的网络数据包是指主机发送或接收的与其他主机或服务器通讯的包含有域名及其对应的IP地址的数据包。例如，DNS应答数据包和/或超文本传输协议HTTP请求数据包。
接着，在步骤S202中，从网络数据包中提取域名与IP地址的对应关系信息。
在本实施例中，从抓取的主机的网络数据包提取域名与IP地址的对应关系，也即从上述网络数据包中抓取数据包指定的域名以及域名对应的IP地址。
之后，在步骤S203中，基于提取的对应关系信息，判断域名系统 DNS是否被劫持。
在本实施例中，基于提取的对应关系信息，判断域名系统DNS是否被劫持，可以通过预先建立的域名与正确IP地址的对应数据库来进行判断，若对应关系信息存在于对应数据库中，则DNS未被劫持，若对应关系信息不存在于对应数据库中，则DNS被劫持。
之后，在步骤S204中，响应于DNS被劫持，将IP地址修改为已确认的IP地址。
在本实施例中，在步骤S203确认域名系统DNS被劫持之后，响应于DNS被劫持，可以将IP地址修改为已确认的IP地址。
其中，已确认的IP地址根据域名与IP地址的已确认对应关系列表得到。该已确认对应关系列表可以为上述的对应数据库的一种表现方式。
然后，在步骤S205中，放行修改IP地址后的网络数据包。
在本实施例中，在步骤S205响应于DNS被劫持，将IP地址修改为已确认的IP地址之后，可以放行修改IP地址后的网络数据包。
上述的防止域名劫持的方法的操作步骤，可以由客户端来完成。例如，客户端可以在抓取本机的网络数据包之后，执行提取域名及其对应的IP地址的操作，之后执行判断是否发生DNS劫持的操作，之后执行若发生DNS劫持则修改IP地址的操作，然后执行放行修改IP地址后的数据包的操作等。
上述的防止域名劫持的方法的操作步骤，也可以由客户端网络传输路径上的网络节点服务器来完成。例如，网络节点服务器可以在抓取主机的网络数据包之后，执行提取域名及其对应的IP地址的操作，之后执行判断是否发生DNS劫持的操作，之后执行若发生DNS劫持则修改IP地址的操作，然后执行放行修改IP地址后的数据包的操作等。
上述的防止域名劫持的方法的操作步骤，还可以部分由客户端来完成，部分由云端服务器来完成。例如，客户端可以抓取本机的网络数据包，之后执行提取域名及其对应的IP地址的操作，之后可以将提取的域名及其对应的IP地址发送至云端服务器，由云端服务器执行之 后的判断是否发生DNS劫持的操作，并将已确认的与提取的域名对应的IP地址返回客户端，由客户端执行修改IP地址的操作，并执行放行修改IP地址后的数据包的操作。
可选地，防止域名劫持的方法还可以包括：响应于DNS未被劫持，放行网络数据包。
本申请上述实施例的防止域名劫持的方法，首先从抓取的主机的网络数据包中提取域名与IP地址的对应关系信息，之后判断DNS是否被劫持，对于被劫持的DNS，将其IP地址修改为已确认的IP地址后放行，使得用户能够正常的访问网络，提高了客户端访问网络的可靠性和安全性。在一些实现方式中，若DNS未被劫持，则放行抓取的网络数据包，提高了主机访问网络的效率。
进一步参考图3，其示出了根据本申请一个实施例的判断DNS是否被劫持的方法的示例性流程图，也即示出了上述步骤203的一种实现方式的流程图。
如图3所示，在步骤301中，查询提取的对应关系信息是否存在于已确认对应关系列表中。
在本实施例中，已确认对应关系列表可以包括多条已确认的对应关系信息，已确认的对应关系信息中包括域名及其对应的IP地址。同一域名可以对应一个或多个已确认的IP地址。已确认的对应关系信息可以根据网络访问数据统计获得，也可以根据预设的已确认的对应关系信息获得。
上述的已确认对应关系列表的存储位置，可以位于以下一个或多个位置：客户端、客户端网络传输路径上的网络节点服务器和云端服务器中。
在查询提取的对应关系信息是否存在于已确认对应关系列表中时，可以以域名为关键词，搜索与域名对应的IP地址中是否包括提取的IP地址，若包括，则确定提取的对应关系信息存在于已确认对应关系列表中，若不包括，则确定提取的对应关系信息存不在于已确认对应关系列表中。
为了提高查询效率，对提取的对应关系信息进行的查询操作可以 在存储已确认对应关系列表的设备上进行，例如，当已确认对应关系列表存储于提取对应关系信息的客户端或网络节点服务器中时，查询操作可以在客户端或网络节点服务器中进行；当已确认对应关系列表存储于云端服务器中时，查询操作可以在云端服务器中进行。
接着，在步骤302中，若对应关系信息不存在于已确认对应关系列表中，则确定DNS被劫持。
本申请上述实施例的判断DNS是否被劫持的方法，通过查询提取的对应关系信息是否存在于已确认的对应关系列表中，从而判断DNS是否被劫持，增加了判断的准确性，并提高了判断效率。
进一步参考图4，其示出了根据本申请另一个实施例的判断DNS是否被劫持的方法的示例性流程图，也即示出了上述步骤203的另一种实现方式的流程图。
在本实施例中，上述实施例的已确认对应关系列表，可以包括存储于云端服务器的云端列表，备选地或附加地，还可以包括从云端列表中获取的本地列表。在从云端列表中获取本地列表时，可以基于以下参数的一项或多项进行获取：客户端的地理位置、网站流量排行、用户访问热度、用户访问时间、用户点击率和用户访问页面数。例如，由于域名在不同地理位置对应的IP地址可能不同，因此可以根据客户端的IP地址判断客户端所在的地理位置，根据其地理位置返回常用域名及其对应的IP地址(若IP地址较多，可以仅返回IP地址列表顶部预设数量的IP地址)。
如图4所示，判断DNS是否被劫持的方法400包括：
步骤401，查询对应关系信息是否存在于本地列表中，若是，则执行步骤402，若否，则执行步骤403；
步骤402，确定DNS未被劫持。
步骤403，查询提取的对应关系信息是否存在于本地已确认DNS劫持的对应关系列表中，若是，则执行步骤404，若否，则执行步骤405；
步骤404，确定DNS被劫持。
步骤405，查询提取的对应关系信息是否存在于云端列表，若是， 则执行步骤406，若否，则执行步骤408；
步骤406，确定DNS未被劫持，之后可以执行步骤407；
步骤407，将对应关系信息存储至本地列表。
步骤408，确定DNS被劫持；
步骤409，将对应关系信息存储至本地已确认DNS劫持的关系列表中。
可选地，在执行上述步骤405时，为了防止因网络问题或云端服务器问题引起的查询云端列表时长时间无响应，降低用户体验，可以预设查询响应的时间，若查询响应的时间超过预设时间，则可以放行网络数据包；若在超过预设时间之后，查询到对应关系信息不存在于云端列表中，则确定DNS被劫持，并且将对应关系信息存储至本地已确认DNS劫持的对应关系列表中；若在超过预设时间之后，查询到对应关系信息存在于云端列表中，则将对应关系信息存储至本地列表。
以上描述了判断DNS是否被劫持的方法的示意性流程图，本领域技术人员应当可以理解，该流程中的一些步骤是可选的而非必要的步骤，例如步骤402和步骤403，在单次执行时可以仅执行其中的一个步骤；步骤404和步骤405，也可以仅执行其中的任一步骤；步骤406和步骤408也可以仅执行其中的任一步骤；而步骤407和步骤409均可以取消。因此，该流程并非对于本申请的限定，以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。
请参考图5，其示出了根据本申请一个实施例的防止域名劫持的装置的结构示意图。
如图5所示，防止域名劫持的装置500可以包括：抓取单元510，提取单元520，判断单元530，修改单元540和第一放行单元550。其中，抓取单元510可以配置用于抓取主机的网络数据包。提取单元520可以配置用于从网络数据包中，提取域名与IP地址的对应关系信息。判断单元530可以配置用于基于提取的对应关系信息，判断域名系统DNS是否被劫持。修改单元540可以配置用于响应于DNS被劫持，将IP地址修改为已确认的IP地址。第一放行单元550可以配置放行修改IP地址后的网络数据包。
在一些实施例中，修改单元中的已确认的IP地址根据域名与IP地址的已确认对应关系列表得到。
可选地，防止域名劫持的装置500还可以包括：第二放行单元560。
第二放行单元560可以配置用于响应于DNS未被劫持，放行网络数据包。
在一些可选的实现方式中，如图6所示，判断单元530可以包括：查询子单元531以及确定子单元532。
查询子单元531，可以配置用于查询提取的对应关系信息是否存在于已确认对应关系列表中。
确定子单元532，可以配置用于若对应关系信息不存在于已确认对应关系列表中，则确定DNS被劫持。
在一些实施例中，已确认对应关系列表可以包括：云端列表，和/或基于以下一项或多项参数从云端列表中获取的本地列表：客户端的地理位置、网站流量排行、用户访问热度、用户访问时间、用户点击率和用户访问页面数。
在一些可选的实现方式中，判断单元530可以包括(未示出)：本地查询子单元，用于查询对应关系信息是否存在于本地列表中。劫持查询子单元，用于响应于对应关系信息不存在于本地列表中，查询对应关系信息是否存在于本地已确认DNS劫持的关系列表中。第一劫持确定子单元，用于响应于对应关系信息存在于本地已确认DNS劫持的关系列表中，确定DNS被劫持。
可选地，判断单元530还可以包括(未示出)：云端查询子单元，用于响应于对应关系信息不存在于本地已确认DNS劫持的关系列表中，查询对应关系信息是否存在于云端列表。第二劫持确定子单元，用于响应于对应关系信息不存在于云端列表，确定DNS被劫持。
对应于上述判断单元530中的已确认对应关系列表可以包括上述的云端列表和本地列表，防止域名劫持的装置500还可以包括：未劫持确定子单元，用于响应于对应关系信息存在于云端列表，则确定DNS未被劫持；以及存储子单元，用于将对应关系信息存储至本地列表。
对应于上述判断单元530中的已确认对应关系列表可以包括上述的云端列表和本地列表，防止域名劫持的装置500还可以包括：第三放行单元，用于若查询对应关系信息是否存在于云端列表的时间超过预设时间，则放行网络数据包。
可选地，对应于上述的防止域名劫持的装置500还可以包括第三放行单元，判断单元530还可以包括：第三劫持确定子单元，可以配置用于若在超过预设时间之后，查询到对应关系信息不存在于云端列表中，则确定DNS被劫持。以及第一存储子单元，可以配置用于将对应关系信息存储至本地已确认DNS劫持的关系列表中。装置500还可以包括：第二存储子单元，可以配置用于若在超过预设时间之后，查询到对应关系信息存在于云端列表中，则将对应关系信息存储至本地列表。
请参考图7，其示出了根据本申请一个实施例的防止域名劫持的装置的应用场景的示意图。
如图7所示，防止域名劫持的装置700可以包括客户端710和云端服务器720。
上述的图5中的防止域名劫持的装置500中的抓取单元510、提取单元520可以由客户端710中的“DNS数据包解析模块”711与“HTTP重定向模块”713实现；判断单元530可以由客户端710中的“DNS安全策略存储与查询模块”712以及云端服务器720中的“云端服务模块”721组合实现；修改单元540可以由“DNS数据包解析模块”711与“HTTP重定向模块”713实现；第一放行单元550可以由客户端710中的“DNS数据包解析模块”711和“HTTP重定向模块”713实现；装置500中的第二放行单元560可以由“DNS数据包解析模块”711实现。
防止域名劫持的装置700，可以通过以下操作步骤防止域名劫持：
步骤1：当客户端第一次启动时，“DNS安全策略存储与查询模块”712从“云端服务模块”721获取一份常用网站域名对应的IP地址列表，由于域名在不同地理位置对应的IP地址可能不同，因此服务器需要根据客户端的IP地址判断客户所在的大概地理位置，根据其地 理位置返回常用域名对应的IP地址(若IP地址较多，仅返回顶部N个IP地址)。
步骤2：“DNS数据包解析模块”711尝试对发往主机的所有DNS应答数据包进行解析，获取其中对应的域名与IP地址的对应关系，根据解析出来的域名与IP的对应关系向“DNS安全策略存储与查询模块”712发起查询请求，判断域名对应的IP地址是否合法。
步骤3：“DNS安全策略存储与查询模块”712在获取到“DNS数据包解析模块”711的查询请求后，首先尝试在本地数据库中进行查询，判断域名对应的IP地址是否在合法列表或者在黑列表(已确认DNS劫持的关系列表)中，若域名对应的IP地址在合法列表中，“DNS安全策略存储与查询模块”712通知“DNS数据包解析模块”711原查询合法，“DNS数据包解析模块”711可以不加修改的放行DNS应答数据包。
步骤4：若在步骤3种发现域名对应的IP地址位于黑列表中，则在域名对应的合法IP地址列表中选择一个IP地址返回给“DNS数据包解析模块”711，“DNS数据包解析模块”711在获取到合法的IP地址时，对原先获取到的DNS应答数据包进行修改，使用合法的IP地址替换原先数据包中的非法IP地址，在修改完毕后将修改后的DNS应答数据包放行。
步骤5：若在步骤3中在本地数据库没有查询到域名与IP地址的关系，则“DNS安全策略存储与查询模块”712向“云端服务模块”721发起云端查询请求，查询域名与IP的安全关系。
步骤6：在步骤5中，若云端查询请求在T时间内(DNS应答数据包不能阻塞过长时间，否则会影响主机系统网络及用户体验，T为一个可配置的数值)应答，则“DNS安全策略存储与查询模块”712根据云端查询请求的结果更新本地数据库相关的白名单(已确认对应关系信息)与黑名单列表，若云端查询请求结果为匹配，则通知“DNS数据包解析模块”711直接放行DNS数据包；若云端查询请求结果为不匹配(可能发生了DNS劫持)，则使用云端查询请求结果中附带的匹配IP通知“DNS数据包解析模块”711修改DNS应答数据包。
步骤7：若在步骤5中云端查询请求结果未能在T时间内返回，则“DNS安全策略存储与查询模块”712需要通知“DNS数据包解析模块”711当前云端查询请求超时，“DNS数据包解析模块”711不加修改的直接放行DNS应答数据包。
步骤8：对于步骤7的情形，待云端查询请求结果在将来某一个时刻应答后，“DNS安全策略存储与查询模块”712需要根据云端查询请求结果更新本地安全策略数据库(白名单与黑名单)。若云端查询请求结果为不匹配，则需要将域名、不匹配IP地址与云端查询请求返回的匹配IP地址这个三元组加入一个专为″HTTP重定向模块″使用的表中。
步骤9：“HTTP重定向模块”713负责监测主机发起的所有HTTP请求数据包，分析其HTTP头部对应的主机域与发往的IP地址，使用域名+IP地址这个二元组向“DNS安全策略存储与查询模块”712发起查询，判断当前的HTTP请求是否收到了DNS劫持影响。
步骤10：“DNS安全策略存储与查询模块”712在接收到“HTTP重定向模块”713的查询请求后，根据域名及IP地址在上述步骤8中的专用表中进行查询，判断域名对应的IP地址是否为不匹配的IP地址(可能发生了DNS劫持)，若发现当前查询的IP地址为不匹配的IP地址，则使用表中记录的匹配IP地址应答“HTTP重定向模块”713，“HTTP重定向模块”713根据获取的IP地址对当前的HTTP数据包进行网络重定向，将数据包发往正确、匹配的IP地址，从而可以避免“DNS数据包解析模块”711因为云端查询请求超时可能造成的无法防住DNS劫持的问题。
应当理解，上述的装置500中记载的诸单元与参考图2描述的方法中的各个步骤相对应。装置600中记载的诸单元与参考图3描述的方法中的各个步骤相对应。由此，上文针对防止DNS劫持的方法描述的操作和特征同样适用于装置500及其中包含的单元，上文针对判断DNS是否被劫持的方法描述的操作和特征同样适用于装置600及其中包含的单元，在此不再赘述。装置500和600中的相应单元可以与客户端设备和/或服务器中的单元相互配合以实现本申请实施例的方案。
本申请上述实施例提供的防止DNS劫持的装置，可以将数据包发往正确、匹配的IP地址，可以提高客户端访问网络的可靠性。
下面参考图8，其示出了适于用来实现本申请实施例的客户端设备或服务器的计算机系统800的结构示意图。
如图8所示，计算机系统800包括中央处理单元(CPU)801，其可以根据存储在只读存储器(ROM)802中的程序或者从存储部分808加载到随机访问存储器(RAM)803中的程序而执行各种适当的动作和处理。在RAM 803中，还存储有系统800操作所需的各种程序和数据。CPU 801、ROM 802以及RAM 803通过总线804彼此相连。输入/输出(I/O)接口805也连接至总线804。
以下部件连接至I/O接口805：包括键盘、鼠标等的输入部分806。包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分807。包括硬盘等的存储部分808。以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至I/O接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分808。
特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括有形地包含在机器可读介质上的计算机程序，计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。
附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，所述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发 生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中，例如，可以描述为：一种处理器包括抓取单元，提取单元、判断单元、修改单元和第一放行单元。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定，例如，抓取单元还可以被描述为“用于抓取主机的网络数据包的单元”。
作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中所述装置中所包含的计算机可读存储介质。也可以是单独存在，未装配入客户端中的计算机可读存储介质。所述计算机可读存储介质存储有一个或者一个以上程序，所述程序被一个或者一个以上的处理器用来执行描述于本申请的防止DNS劫持的方法。
以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离所述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (26)

  1. 一种防止域名劫持的方法，其特征在于，包括：
    抓取主机的网络数据包；
    从所述网络数据包中提取域名与IP地址的对应关系信息；
    基于提取的对应关系信息，判断域名系统DNS是否被劫持；
    响应于所述DNS被劫持，将所述IP地址修改为已确认的IP地址；
    放行修改IP地址后的网络数据包。
  2. 根据权利要求1所述的方法，其特征在于，所述网络数据包包括：DNS应答数据包和/或超文本传输协议HTTP请求数据包。
  3. 根据权利要求1所述的方法，其特征在于，所述已确认的IP地址根据域名与IP地址的已确认对应关系列表得到。
  4. 根据权利要求3所述的方法，其特征在于，所述基于提取的对应关系信息，判断域名系统DNS是否被劫持包括：
    查询提取的对应关系信息是否存在于所述已确认对应关系列表中；
    若不存在，则确定DNS被劫持。
  5. 根据权利要求1所述的方法，其特征在于，所述方法还包括：响应于DNS未被劫持，放行所述网络数据包。
  6. 根据权利要求3所述的方法，其特征在于，所述已确认对应关系列表包括：
    云端列表；和/或
    基于以下一项或多项参数从所述云端列表中获取的本地列表：客户端的地理位置、网站流量排行、用户访问热度、用户访问时间、用户点击率和用户访问页面数。
  7. 根据权利要求6所述的方法，其特征在于，所述基于提取的对应关系信息，判断域名系统DNS是否被劫持包括：
    查询提取的对应关系信息是否存在于所述本地列表中；
    响应于提取的对应关系信息不存在于所述本地列表中，查询提取的对应关系信息是否存在于本地已确认DNS劫持的对应关系列表中；
    响应于提取的对应关系信息存在于本地已确认DNS劫持的对应关系列表中，确定DNS被劫持。
  8. 根据权利要求7所述的方法，其特征在于，所述基于提取的对应关系信息，判断域名系统DNS是否被劫持还包括：
    响应于提取的对应关系信息不存在于本地已确认DNS劫持的关系列表中，查询提取的对应关系信息是否存在于所述云端列表；
    响应于提取的对应关系信息不存在于所述云端列表，确定所述DNS被劫持。
  9. 根据权利要求8所述的方法，其特征在于，所述方法还包括：
    响应于提取的对应关系信息存在于所述云端列表，则确定所述DNS未被劫持；
    将所述对应关系信息存储至本地列表。
  10. 根据权利要求8所述的方法，其特征在于，所述方法还包括：
    若查询提取的对应关系信息是否存在于所述云端列表的时间超过预设时间，则放行所述网络数据包。
  11. 根据权利要求10所述的方法，其特征在于，所述基于提取的对应关系信息，判断域名系统DNS是否被劫持还包括：
    若在超过所述预设时间之后，查询到所述对应关系信息不存在于所述云端列表中，则确定所述DNS被劫持，并且将所述对应关系信息存储至本地已确认DNS劫持的关系列表中。
  12. 根据权利要求11所述的方法，其特征在于，所述方法还包括：
    若在超过所述预设时间之后，查询到所述对应关系信息存在于所述云端列表中，则将所述对应关系信息存储至本地列表。
  13. 一种防止域名劫持的装置，其特征在于，包括：
    抓取单元，用于抓取主机的网络数据包；
    提取单元，用于从所述网络数据包中，提取域名与IP地址的对应关系信息；
    判断单元，用于基于提取的对应关系信息，判断域名系统DNS是否被劫持；
    修改单元，用于响应于所述DNS被劫持，将所述IP地址修改为已确认的IP地址；
    第一放行单元，放行修改IP地址后的网络数据包。
  14. 根据权利要求13所述的装置，其特征在于，所述网络数据包包括：DNS应答数据包和/或超文本传输协议HTTP请求数据包。
  15. 、根据权利要求13所述的装置，其特征在于，所述修改单元中的已确认的IP地址根据域名与IP地址的已确认对应关系列表得到。
  16. 根据权利要求15所述的装置，其特征在于，所述判断单元包括：
    查询子单元，用于查询提取的对应关系信息是否存在于所述已确认对应关系列表中；
    确定子单元，用于若所述对应关系信息不存在于所述已确认对应关系列表中，则确定DNS被劫持。
  17. 根据权利要求13所述的装置，其特征在于，所述装置还包括：
    第二放行单元，用于响应于DNS未被劫持，放行所述网络数据包。
  18. 根据权利要求15所述的装置，其特征在于，所述已确认对应关系列表包括：
    云端列表；和/或
    基于以下一项或多项参数从所述云端列表中获取的本地列表：客户端的地理位置、网站流量排行、用户访问热度、用户访问时间、用户点击率和用户访问页面数。
  19. 根据权利要求18所述的装置，其特征在于，判断单元包括：
    本地查询子单元，用于查询提取的对应关系信息是否存在于所述本地列表中；
    劫持查询子单元，用于响应于提取的对应关系信息不存在于所述本地列表中，查询提取的对应关系信息是否存在于本地已确认DNS劫持的关系列表中；
    第一劫持确定子单元，用于响应于提取的对应关系信息存在于本地已确认DNS劫持的关系列表中，确定DNS被劫持。
  20. 根据权利要求19所述的装置，其特征在于，所述判断单元还包括：
    云端查询子单元，用于响应于提取的对应关系信息不存在于本地已确认DNS劫持的关系列表中，查询提取的对应关系信息是否存在于所述云端列表；
    第二劫持确定子单元，用于响应于提取的对应关系信息不存在于所述云端列表，确定所述DNS被劫持。
  21. 根据权利要求20所述的装置，其特征在于，所述装置还包括：
    未劫持确定子单元，用于响应于提取的对应关系信息存在于所述云端列表，则确定所述DNS未被劫持；
    存储子单元，用于将所述对应关系信息存储至本地列表。
  22. 根据权利要求20所述的装置，其特征在于，所述装置还包括：
    第三放行单元，用于若查询提取的对应关系信息是否存在于所述云端列表的时间超过预设时间，则放行所述网络数据包。
  23. 根据权利要求22所述的装置，其特征在于，所述基于提取的对应关系信息，判断域名系统DNS是否被劫持还包括：
    第三劫持确定子单元，用于若在超过所述预设时间之后，查询到所述对应关系信息不存在于所述云端列表中，则确定所述DNS被劫持；以及
    第一存储子单元，用于将所述对应关系信息存储至本地已确认DNS劫持的关系列表中。
  24. 根据权利要求23所述的装置，其特征在于，所述装置还包括：
    第二存储子单元，用于若在超过所述预设时间之后，查询到所述对应关系信息存在于所述云端列表中，则将所述对应关系信息存储至本地列表。
  25. 一种设备，包括：
    处理器；和
    存储器，
    所述存储器中存储有能够被所述处理器执行的计算机可读指令，在所述计算机可读指令被执行时，所述处理器执行权利要求1至12中任一项所述的方法。
  26. 一种非易失性计算机存储介质，所述计算机存储介质存储有能够被处理器执行的计算机可读指令，当所述计算机可读指令被处理器执行时，所述处理器执行权利要求1至12中任一项所述的方法。
PCT/CN2015/098224 2015-07-07 2015-12-22 防止域名劫持的方法和装置 WO2017004947A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510394124.7 2015-07-07
CN201510394124.7A CN106330849A (zh) 2015-07-07 2015-07-07 防止域名劫持的方法和装置

Publications (1)

Publication Number Publication Date
WO2017004947A1 true WO2017004947A1 (zh) 2017-01-12

Family

ID=57684760

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/098224 WO2017004947A1 (zh) 2015-07-07 2015-12-22 防止域名劫持的方法和装置

Country Status (2)

Country Link
CN (1) CN106330849A (zh)
WO (1) WO2017004947A1 (zh)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109257373A (zh) * 2018-10-31 2019-01-22 腾讯科技（深圳）有限公司 一种域名劫持识别方法、装置及系统
CN109451053A (zh) * 2018-12-18 2019-03-08 广州市百果园信息技术有限公司 页面资源请求消息发送方法、装置、介质和计算机设备
CN110602048A (zh) * 2019-08-14 2019-12-20 中国平安财产保险股份有限公司 防止域名劫持的方法、装置及计算机设备
CN111600840A (zh) * 2020-04-16 2020-08-28 五八有限公司 一种dns劫持的处理方法及装置
CN112911617A (zh) * 2021-01-20 2021-06-04 广东工贸职业技术学院 数据传输方法、装置、计算机设备和存储介质
CN113364722A (zh) * 2020-03-04 2021-09-07 阿里巴巴集团控股有限公司 网络安全防护方法和装置
CN113872978A (zh) * 2021-09-29 2021-12-31 绿盟科技集团股份有限公司 一种dns劫持的监测方法、装置及电子设备
CN113922987A (zh) * 2021-07-12 2022-01-11 北京宇创瑞联信息技术有限公司 数据安全传输方法、设备和系统
CN113938478A (zh) * 2021-09-13 2022-01-14 杭州当贝网络科技有限公司 一种下载的方法和系统
CN114124491A (zh) * 2021-11-12 2022-03-01 中国电信股份有限公司 防旁路劫持方法和系统、入口和出口交换机、安全网元
CN114285821A (zh) * 2021-11-17 2022-04-05 奇安信科技集团股份有限公司 一种域名解析方法、装置、电子设备、存储介质及产品
CN114465791A (zh) * 2022-01-25 2022-05-10 杭州盈高科技有限公司 网管设备中白名单的建立方法、装置、存储介质及处理器

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106888280A (zh) * 2017-03-29 2017-06-23 北京奇虎科技有限公司 Dns更新方法、装置及系统
CN106899711A (zh) * 2017-05-09 2017-06-27 南京赢纳信息科技有限公司 一种基于Linux的动态域名解析模块及其黑白名单实现方法
CN108881146A (zh) * 2017-12-28 2018-11-23 北京安天网络安全技术有限公司 域名系统劫持的识别方法、装置、电子设备及存储介质
CN108282495B (zh) * 2018-03-14 2021-10-15 北京奇艺世纪科技有限公司 一种dns劫持防御方法和装置
CN110266830A (zh) * 2019-06-17 2019-09-20 四川长虹电器股份有限公司 域名系统劫持的修复方法及系统
CN110445798B (zh) * 2019-08-14 2021-09-17 北京声智科技有限公司 Dns防劫持方法、装置及电子设备
CN110912925A (zh) * 2019-12-04 2020-03-24 北京小米移动软件有限公司 检测域名系统dns劫持的方法及装置、存储介质
CN111447226B (zh) * 2020-03-27 2022-08-12 上海尚往网络科技有限公司 用于检测dns劫持的方法和设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030182447A1 (en) * 2001-05-31 2003-09-25 Schilling Frank T. Generic top-level domain re-routing system
CN102271168A (zh) * 2011-09-14 2011-12-07 吴兴利 修改dns回复ip的手段屏蔽和劫持互联网弹窗的方法
US20130036468A1 (en) * 2011-08-01 2013-02-07 Visicom Media Inc. Anti-phishing domain advisor and method thereof
CN104683330A (zh) * 2015-02-06 2015-06-03 广州酷狗计算机科技有限公司 反域名劫持方法和装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060036418A (ko) * 2006-03-22 2006-04-28 문종섭 유알엘 스푸핑 이용한 피싱 공격을 방어하기 위한 네트워크보안 시스템의 구성과 동작 순서
CN102082836B (zh) * 2009-11-30 2013-08-14 中国移动通信集团四川有限公司 一种dns安全监控系统及方法
CN102868773B (zh) * 2012-08-22 2015-04-15 北京奇虎科技有限公司 检测dns黑洞劫持的方法、装置及系统
CN103561120B (zh) * 2013-10-08 2017-06-06 北京奇虎科技有限公司 检测可疑dns的方法、装置和可疑dns的处理方法、系统
CN104092787B (zh) * 2014-06-24 2016-04-13 腾讯科技（深圳）有限公司 基于dns的网络访问方法和系统
CN104168339A (zh) * 2014-06-30 2014-11-26 汉柏科技有限公司 防止域名劫持的方法及设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030182447A1 (en) * 2001-05-31 2003-09-25 Schilling Frank T. Generic top-level domain re-routing system
US20130036468A1 (en) * 2011-08-01 2013-02-07 Visicom Media Inc. Anti-phishing domain advisor and method thereof
CN102271168A (zh) * 2011-09-14 2011-12-07 吴兴利 修改dns回复ip的手段屏蔽和劫持互联网弹窗的方法
CN104683330A (zh) * 2015-02-06 2015-06-03 广州酷狗计算机科技有限公司 反域名劫持方法和装置

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109257373A (zh) * 2018-10-31 2019-01-22 腾讯科技（深圳）有限公司 一种域名劫持识别方法、装置及系统
CN109257373B (zh) * 2018-10-31 2020-12-04 腾讯科技（深圳）有限公司 一种域名劫持识别方法、装置及系统
CN109451053A (zh) * 2018-12-18 2019-03-08 广州市百果园信息技术有限公司 页面资源请求消息发送方法、装置、介质和计算机设备
CN109451053B (zh) * 2018-12-18 2022-02-25 广州市百果园信息技术有限公司 页面资源请求消息发送方法、装置、介质和计算机设备
CN110602048A (zh) * 2019-08-14 2019-12-20 中国平安财产保险股份有限公司 防止域名劫持的方法、装置及计算机设备
CN113364722A (zh) * 2020-03-04 2021-09-07 阿里巴巴集团控股有限公司 网络安全防护方法和装置
CN111600840B (zh) * 2020-04-16 2022-03-04 五八有限公司 一种dns劫持的处理方法及装置
CN111600840A (zh) * 2020-04-16 2020-08-28 五八有限公司 一种dns劫持的处理方法及装置
CN112911617A (zh) * 2021-01-20 2021-06-04 广东工贸职业技术学院 数据传输方法、装置、计算机设备和存储介质
CN113922987A (zh) * 2021-07-12 2022-01-11 北京宇创瑞联信息技术有限公司 数据安全传输方法、设备和系统
CN113938478A (zh) * 2021-09-13 2022-01-14 杭州当贝网络科技有限公司 一种下载的方法和系统
CN113938478B (zh) * 2021-09-13 2024-04-09 杭州当贝网络科技有限公司 一种下载的方法和系统
CN113872978A (zh) * 2021-09-29 2021-12-31 绿盟科技集团股份有限公司 一种dns劫持的监测方法、装置及电子设备
CN113872978B (zh) * 2021-09-29 2024-03-15 绿盟科技集团股份有限公司 一种dns劫持的监测方法、装置及电子设备
CN114124491A (zh) * 2021-11-12 2022-03-01 中国电信股份有限公司 防旁路劫持方法和系统、入口和出口交换机、安全网元
CN114285821A (zh) * 2021-11-17 2022-04-05 奇安信科技集团股份有限公司 一种域名解析方法、装置、电子设备、存储介质及产品
CN114465791A (zh) * 2022-01-25 2022-05-10 杭州盈高科技有限公司 网管设备中白名单的建立方法、装置、存储介质及处理器
CN114465791B (zh) * 2022-01-25 2024-04-30 杭州盈高科技有限公司 网管设备中白名单的建立方法、装置、存储介质及处理器

Also Published As

Publication number Publication date
CN106330849A (zh) 2017-01-11

Similar Documents

Publication Publication Date Title
WO2017004947A1 (zh) 防止域名劫持的方法和装置
US8935419B2 (en) Filtering device for detecting HTTP request and disconnecting TCP connection
US10263958B2 (en) Internet mediation
US20190173904A1 (en) Entity Group Behavior Profiling
CN110213212B (zh) 一种设备的分类方法和装置
US8645503B1 (en) Accelerated data uploading
CN106936791B (zh) 拦截恶意网址访问的方法和装置
US9578040B2 (en) Packet receiving method, deep packet inspection device and system
EP3170091B1 (en) Method and server of remote information query
US9554276B2 (en) System and method for on the fly protocol conversion in obtaining policy enforcement information
US20140310811A1 (en) Detecting and Marking Client Devices
CN112261172B (zh) 服务寻址访问方法、装置、系统、设备及介质
US20130007882A1 (en) Methods of detecting and removing bidirectional network traffic malware
US20130007870A1 (en) Systems for bi-directional network traffic malware detection and removal
JPWO2016006520A1 (ja) 検知装置、検知方法及び検知プログラム
US8914510B2 (en) Methods, systems, and computer program products for enhancing internet security for network subscribers
CN104219200A (zh) 一种防范dns缓存攻击的装置和方法
WO2021027600A1 (zh) 单点登录方法、装置、设备及计算机可读存储介质
US11770385B2 (en) Systems and methods for malicious client detection through property analysis
WO2020228038A1 (zh) 域名处理方法、装置、电子设备以及存储介质
WO2017096888A1 (zh) 域名解析系统的实现方法及装置
WO2014048746A1 (en) Device, system and method for reducing attacks on dns
JP2014501959A (ja) ユーザにサービスアクセスを提供する方法およびシステム
CN108886533B (zh) 加速与主机服务器的连接
CN106789882A (zh) 一种域名请求攻击的防御方法及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15897596

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 24/04/2018)

122 Ep: pct application non-entry in european phase

Ref document number: 15897596

Country of ref document: EP

Kind code of ref document: A1