Methods and apparatus for blocking, detecting and / or preventing malicious traffic

Abstract

Embodiments of the present disclosure relate to methods and devices for blocking, detecting and / or preventing malicious traffic. A network device obtains information associated with a blacklisted domain, which includes a blacklisted domain identifier and a sinkhole server identifier associated with the blacklisted domain identifier. The network device obtains a set of rules that specify matching criteria associated with the blacklisted domain, the matching criteria including a source network address and / or a destination network address for comparing a packet source network address and / or a packet destination network address associated with an incoming packet. The set of rules specifies an action to be performed based on a comparison result of the matching criteria and the packet source network address and / or the packet destination network address of the incoming packet. The network device receives a packet, checks the packet source network address and / or the packet destination network address associated with the packet, compares the packet source network address and / or the packet destination network address with the matching criteria, and performs an action based on the result of the comparison.

Description

[0001] This application is a divisional application of the Chinese invention patent application with the national application date of June 13, 2019, the national application number of 201910510528.6, and the invention name of “Methods and devices for blocking, detecting and / or preventing malicious traffic”. Technical Field

[0002] Embodiments of the present disclosure relate generally to the field of network traffic, and more particularly to methods and apparatus for blocking, detecting, and / or preventing malicious traffic. Background Art

[0003] The Domain Name System (DNS) is a protocol within a collection of standards known as the Internet Protocol Suite for how computers exchange data on the Internet and many private networks. The DNS service is used to resolve Internet Protocol (IP) addresses associated with domain names. DNS sinkholing can be used to provide incorrect DNS resolution by which the path of Internet traffic can be directed to a different resource (e.g., a sinkhole server) rather than allowing access to malicious or inaccessible content. DNS sinkholing is a method of redirecting malicious Internet traffic so that it can be captured and analyzed. Summary of the invention

[0004] According to some possible implementations, a method may include obtaining, by a processor, information associated with a plurality of blacklisted domains, wherein the information includes a blacklisted domain identifier corresponding to a blacklisted domain in the plurality of blacklisted domains. The method may include determining, by the processor, a network address of a device hosting the plurality of blacklisted domains based on collecting Domain Name System (DNS) data associated with the blacklisted domain identifier, and storing, by the processor, in a data structure, the network address of the device hosting the plurality of blacklisted domains and the blacklisted domain identifier corresponding to the blacklisted domain in the plurality of blacklisted domains. The method may include receiving, by the processor, one or more packets destined for a destination device associated with a destination network address, comparing, by the processor, the destination network address with a network address stored in the data structure, and performing, by the processor, an action based on the result of comparing the destination network address with the network address.

[0005] According to some possible implementations, a method may include obtaining, by a processor, information associated with a plurality of blacklisted domains, wherein the information includes a blacklisted domain identifier corresponding to a blacklisted domain in the plurality of blacklisted domains. The method may include obtaining, by a processor, a plurality of source network address prefixes, wherein a source network address prefix in the plurality of source network address prefixes is associated with a possible attacker. The method may include receiving, by a processor, a Domain Name System (DNS) request or query, wherein the DNS request includes a request to access a destination domain associated with a destination domain identifier, and a source network address corresponding to a device from which the DNS request is received. The method may include determining, by a processor, that the destination domain identifier corresponds to a blacklisted domain identifier in the blacklisted domain identifiers, obtaining, by the processor, a threat level associated with the blacklisted domain identifier, and determining, by the processor, whether the threat level associated with the blacklisted domain identifier meets a threshold. The method may include comparing, by a processor, a prefix of a source network address with a plurality of source network address prefixes, and performing, by the processor, an action based on a result of whether the threat level associated with the blacklisted domain identifier meets a threshold and a result of comparing the prefix of the source network address with a plurality of source network address prefixes.

[0006] According to some possible implementations, a network device may include one or more memories, and one or more processors communicatively coupled to the one or more memories, to obtain information associated with a plurality of blacklisted domains, wherein the information includes blacklisted domain identifiers and sinkhole server identifiers associated with the blacklisted domain identifiers. The one or more processors may obtain a set of rules, wherein the set of rules specifies matching criteria associated with a plurality of blacklisted domains, wherein the matching criteria include a plurality of source network addresses and / or a plurality of destination network addresses for comparison with a packet source network address and / or a packet destination network address associated with an incoming packet, and wherein the set of rules specifies an action to be performed based on a result of comparing the matching criteria and the packet source network address and / or the packet destination network address for the incoming packet. The one or more processors may receive one or more packets, check the packet source network address and / or the packet destination network address associated with the one or more packets, compare the packet source network address and / or the packet destination network address with the matching criteria, and perform an action based on a result of comparing the packet source network address and / or the packet destination network address with the matching criteria specified by the set of rules. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1A-Figure 1C is a diagram of an example implementation described herein.

[0008] Figure 2A-2D is a diagram of an example implementation described herein.

[0009] Figure 3 is a diagram of an example environment in which the systems and / or methods described herein may be implemented.

[0010] Figure 4A-4B yes Figure 3 A diagram of example components of one or more devices.

[0011] Figure 5 is a flow chart of an example process for blocking, detecting, and / or preventing malicious traffic.

[0012] Figure 6 is a flow chart of an example process for blocking, detecting, and / or preventing malicious traffic.

[0013] Figure 7 is a flow chart of an example process for blocking, detecting, and / or preventing malicious traffic. DETAILED DESCRIPTION

[0014] The following detailed description of example implementations refers to the accompanying drawings.The same reference numbers in different drawings may identify the same or similar elements.

[0015] Different types of malicious attacks can occur in a network. For example, in some cases, a user may be directed to an attacker's website and inadvertently download malicious content from the website. In other cases, an attacker may bombard a service provider's resources and consume excessive bandwidth. Network or cloud-based firewall devices designed to prevent malicious attacks can implement Domain Name System (DNS) sinkhole functionality, where suspicious traffic received from or sent to suspicious resources can be redirected to a sinkhole server for further analysis. However, intelligent attackers have designed methods to bypass the DNS sinkhole functionality implemented by firewall devices when performing malicious attacks. In addition, in some cases, an attacker may deliberately bombard a sinkhole server with traffic from an attack, which is intended to consume bandwidth and overload the sinkhole server, which interferes with the sinkhole server's ability to perform traffic analysis.

[0016] Some implementations described herein include security devices configured to block, detect, and / or prevent malicious traffic in a network. The security device can be implemented as a network device (e.g., a routing device, etc.) and / or a device attached to a network device (e.g., a physical interface card of a routing device, etc.).

[0017] In some implementations, the security device described herein can block malicious traffic in a network. For example, a country (e.g., the United States, the United Kingdom, etc.), an organization, or a customer can specify a list of blacklisted domains that the country or customer wishes to block users from accessing. For example, a blacklisted domain may be associated with an attacker's device or an attacker's website. In some implementations, the security device described herein is configured to actively perform DNS mining techniques to resolve network addresses for devices hosting blacklisted domains. The security device can utilize matching criteria included in matching-based filters and / or rules to block traffic to resolved network addresses. For example, a security device can block traffic to a network address associated with a network server hosting a blacklisted domain and redirect the traffic to a sinkhole server. In this way, network security can be improved because malicious traffic and / or access to malicious content is more effectively blocked. In this way, traffic from attackers who bypass DNS sinkhole functionality can be blocked, recorded, and / or prevented from accessing intended destinations.

[0018] In some implementations, the security devices described herein can detect malicious traffic in a network and / or prevent malicious traffic from reaching back-end devices (e.g., servers, sinkhole servers, etc.) in the network. For example, the security device described herein can receive a DNS request, determine that the DNS request is associated with a possible attacker, and respond to the DNS request with a DNS response including a time-to-live value set to zero. Setting the time-to-live value to zero in the DNS response prevents the DNS response from being cached by a possible attacker. In this way, a possible attacker may be forced to send additional DNS requests in an attempt to access devices in the network. Subsequent additional DNS requests received from the same source network address can be recorded and investigated. In the event that the count of DNS requests meets a threshold, the source device can be considered an attacker device, and the security device can notify a cloud-based security platform so that the attacker device can be blocked globally. In this way, security on one or more networks can be improved because attackers can be cleverly identified and prevented from reaching back-end devices in one or more networks.

[0019] Figure 1A-Figure 1C is a diagram of an example implementation 100 described herein. Figure 1A-Figure 1CAs shown in , an example implementation 100 may include a security platform that includes a DNS sinkhole data structure, a routing device, a forwarding component, a security device, a client device, a server device, and / or a sinkhole server device. The routing device and / or the security device may include, alone or in combination, a DNS mining / web filtering module as described herein, by which network addresses associated with blacklisted domains may be parsed, detected, and / or blocked (e.g., using filters or rules). In some implementations, the routing device may include a firewall module as described herein, by which the forwarding component may be configured or directed to forward traffic (i.e., packets) to the security device for inspection. The example implementation 100 may be provided in a public or private network provided by a network service provider.

[0020] like Figure 1A As shown in , and by reference numeral 102, the routing device may receive or obtain information from the security platform, including information stored in a DNS sinkhole data structure or database (DB) of the security platform. The security platform may include a local or cloud-based security solution (e.g., a firewall, etc.) configured to detect threats and implement DNS sinkhole functionality. For example, the DNS sinkhole functionality may include: receiving a DNS request, comparing the domain name received in the DNS request with a blacklisted domain identifier stored in the DNS sinkhole data structure, and responding to the DNS request using the network address of the sinkhole server associated with the blacklisted domain identifier. In this way, traffic sent to the blacklisted domain can be directed to the sinkhole server device for further logging and inspection. In some implementations, the blacklisted domain may be associated with an attacker or an attacker's website, and the customer (e.g., a country, a network service provider, a network operator, etc.) determines that it should be blocked. However, smart hackers and / or malicious attackers can bypass the security platform as described herein. Thus, in some implementations, information stored by the security platform may be obtained by a routing device for use in blocking traffic sent by and / or received from an attacker who may bypass the security platform.

[0021] In some implementations, the information obtained by the routing device may include, for example, a list of blacklisted domain identifiers associated with blacklisted domain names, network addresses for one or more sinkhole servers associated with the blacklisted domain identifiers (i.e., Internet Protocol (IP) addresses), network address ranges of blacklisted devices (i.e., IP ranges), network address prefixes of blacklisted devices (i.e., IP prefixes), etc. In some implementations, the network addresses for one or more sinkhole servers associated with the blacklisted domain identifiers include sinkhole server identifiers, which may correspond to IPv4 addresses and / or IPv6 addresses. In some implementations, the routing device may obtain information from the security platform via downloading, extracting, subscribing to receive a feed from the security platform, streaming information in real time or near real time, receiving push notifications, etc. In some implementations, the security platform exports the information to the routing device and exports, streams, or otherwise transmits updated information in real time or periodically.

[0022] like Figure 1A As further shown in , and by reference numeral 104, the routing device may send information obtained from the security platform to the security device. In some implementations, the routing device sends the blacklisted domain identifier to the security device for DNS evaluation or mining, whereby the security device may proactively determine a network address associated with a device hosting the blacklisted domain. For example, in some implementations, the security device may obtain the blacklisted domain identifier and implement DNS crawling and / or DNS snooping techniques by which the security device collects DNS data associated with the blacklisted domain identifier. In this manner, the security device may determine or resolve a network address of the blacklisted domain and / or a network address associated with the blacklisted domain. In this manner, traffic from an attacker that bypasses the DNS sinkhole functionality implemented by the security platform (e.g., traffic destined for a network address of a device hosting a blacklisted domain) may be blocked and / or redirected to a sinkhole server despite having bypassed the security platform.

[0023] like Figure 1AAs further shown in FIG. 1 and by reference numeral 106, the security device may use DNS mining techniques (e.g., DNS crawling, DNS snooping, etc.) to determine network addresses associated with blacklisted domains. For example, and in some implementations, the security device may use DNS crawling techniques to determine network addresses associated with blacklisted domains. In this regard, the security device may generate a DNS request including a blacklisted domain identifier, send the DNS request to a DNS server, receive a response to the DNS request from the DNS server, and cache the network address included in the response to the DNS request. In some implementations, the security device may actively perform DNS resolution for the blacklisted domains periodically or according to a schedule. For example, the security device may generate and send DNS requests for blacklisted domains in the list of blacklisted domains every second (e.g., 50 requests per second, 20 requests per second, etc.), every 10 seconds (e.g., 500 requests per 10 seconds, 200 requests per 10 seconds, etc.), and so on.

[0024] As another example, and in some implementations, the security device may use DNS listening techniques to determine the network addresses associated with the blacklisted domains. In this regard, the security device may intercept (e.g., listen) DNS messages exchanged between or by a DNS resolver device and a DNS server device. The DNS message may include one or more packets indicating or including the network address of a device hosting multiple blacklisted domains. The security device may cache the network addresses included in the intercepted DNS message. In this way, the security device may resolve the IPv4 and IPv6 network addresses associated with a given blacklisted domain for inclusion in a data structure (e.g., a blacklisted domain data structure) that can be evaluated and / or stored by the security device and / or routing device, through which the security device and / or routing device can filter and / or block users from accessing the device hosting the blacklisted domain and / or the malicious content available in the blacklisted domain. In some implementations, a single blacklisted domain identifier may be resolved to multiple network addresses and / or associated with multiple network addresses. The multiple network addresses may include one or more IPv4 network addresses and / or one or more IPv6 network addresses.

[0025] like Figure 1A As further shown in FIG. 1 and by reference numeral 108, the security device may send the network address for the blacklisted domain to the routing device. The network address for the blacklisted domain may be used when filtering and / or redirecting traffic to the blacklisted domain. Figure 1AAs shown in , and by reference numeral 110, the routing device may store the resolved network addresses associated with the blacklisted domains in the data structure as blacklisted domain data. The routing device may collect, aggregate, store and / or construct a data structure containing information associated with the blacklisted domains and / or devices hosting the blacklisted domains obtained from the security platform. In some implementations, the data structure includes the resolved network addresses associated with the blacklisted domains for use in filtering and / or blocking traffic to the blacklisted domains. In some implementations, the data stored by the routing device may additionally include a blacklisted domain identifier obtained from the security platform, a network address associated with the blacklisted domain identifier resolved by the security device, a list of sinkhole server device identifiers (e.g., a sinkhole IPv4 address, a sinkhole IPv6 address, etc.) associated with the blacklisted domain identifier obtained from the security platform, a suspicious source network address obtained from the security platform, a suspicious source network address prefix obtained from the security platform, and the like.

[0026] like Figure 1A As further shown in FIG. 1 and by reference numeral 112, the security device may establish a filter (e.g., a traffic filter) based on the resolved network address associated with the blacklisted domain identifier and / or other information stored by the routing device. In some implementations, as shown by reference numeral 114, the firewall module of the routing device may establish and install a filter on the forwarding component, and the forwarding component may take specific actions based on the incoming traffic and / or information contained in the packet header of the incoming traffic through the filter. For example, the forwarding component may drop traffic, forward traffic, log traffic, etc. based on the filter installed by the firewall module of the routing device. In some implementations, the forwarding component may perform an action based on the source information and / or destination information contained in the packet header of the incoming traffic, and forward the traffic to the security device for inspection. For example, the forwarding component may forward packets with suspicious source network addresses, suspicious source network address prefixes, etc. to the security device for inspection. As another example, the forwarding component may forward packets with a destination network address associated with a device hosting a blacklisted domain to the security device for inspection.

[0027] like Figure 1AAs further shown in , and by reference numeral 116, a security device may generate, create, establish, specify, or otherwise provide a set of filters or rules, including matching criteria (e.g., based on matching criteria) and / or actions performed based on satisfying the matching criteria. For example, rules may be used when filtering incoming traffic in a forward and reverse direction based on source or destination network addresses contained in packet headers of the incoming traffic to identify and / or block traffic received from and / or sent to a blacklisted domain. As an example, a rule may filter incoming traffic based on comparing the source network address and / or destination network address of an incoming packet to information stored or contained in a data structure (e.g., a blacklisted domain, a resolved network address of a device hosting a blacklisted domain, etc.), and perform an action based on the comparison result.

[0028] In some implementations, in the event that incoming traffic includes a source network address and / or a destination network address that matches a network address contained in a data structure, the traffic can be redirected to a sinkhole server. In some implementations, multiple sinkhole servers are associated with blacklisted domains. In some implementations, in the event that a source or destination network address for incoming traffic matches a network address associated with a blacklisted domain, the security device can perform a lookup in the data structure and obtain a sinkhole server identifier associated with the blacklisted domain. The security device can select a sinkhole server to which the traffic can be redirected. In some implementations, the security device can perform HTTP redirection on the traffic (e.g., for HTTP or HTTPS traffic), or perform network address translation (NAT) on the traffic (e.g., for non-HTTP and / or non-HTTPS traffic), as described herein.

[0029] like Figure 1B As shown in FIG. 1 and by reference numeral 118, a routing device may receive traffic from a client device. In some implementations, the traffic may be L4-L7 traffic (e.g., HTTP traffic, HTTPS traffic, non-HTTP traffic, etc.) that includes a network address and has bypassed the security platform ( Figure 1A ). In some implementations, the traffic may not have bypassed the security platform. The routing device and / or the security device are configured to inspect and / or filter the traffic based on source network address, source port identifier, destination network address, and / or destination port identifier information contained in a packet header of the traffic. In some implementations, the traffic may be sent to a server device as determined based on inspecting routing information contained in a packet header associated with the traffic. The server device may or may not correspond to a server device hosting a blacklisted domain.

[0030] like Figure 1BAs further shown in FIG. 1 and by reference numeral 120, traffic may be received by a forwarding component. In some implementations, the forwarding component may be incorporated within a routing device. Figure 1B As shown in , and by reference numeral 122, the forwarding component can evaluate traffic using a filter installed by a firewall module at the forwarding component. In some implementations, the filter is based on comparing the source network address, source port identifier, destination network address or destination port identifier with the information contained in the data structure. For example, in the case where the destination network address of the incoming packet matches the resolved network address corresponding to the blacklisted domain identifier stored in the data structure, the forwarding component can forward traffic to the security device for further evaluation and / or inspection. Similarly, in the case where the source network address of the incoming packet matches the source network address or includes a source prefix that matches the source prefix stored in the data structure, the forwarding component can forward traffic to the security device for further inspection. In addition, in some implementations, in the case where the source and / or destination network address of the incoming packet does not correspond to any network address stored in the data structure, the forwarding component can allow traffic and forward traffic to the server device.

[0031] like Figure 1B As further shown in and by reference numeral 124, the forwarding component can selectively forward traffic to a server device or a security device based on the results of evaluating the traffic using a filter. As described above, in the event that the source network address, destination network address, source identifier (e.g., source port identifier) ​​and / or destination identifier (e.g., destination port identifier) ​​of the incoming traffic matches the network address or identifier stored in the data structure, the traffic can be forwarded to the security device for further inspection. Additionally or alternatively, in the event that the source network address, destination network address, source identifier and / or destination identifier of the incoming traffic do not match any network address and / or identifier stored in the data structure, the traffic can be allowed and forwarded to the server device.

[0032] like Figure 1C As shown in , and by reference numeral 126, the forwarding component can forward the traffic to the security device. In this case, for example, header information for the traffic received by the forwarding component can correspond to information contained in the data structure, and thus will receive further inspection, evaluation, and / or action provided by the security device. Accordingly, the forwarding component can selectively forward the traffic to the security device, such as in instances where the source network address, destination network address, source identifier, and / or destination identifier of the incoming traffic matches the network addresses and or identifiers stored in the data structure.

[0033] like Figure 1CAs further shown in , and by reference numeral 128, the security device may receive traffic from the forwarding component and compare the source network address, destination network address, source identifier, and / or destination identifier of the traffic with information associated with the blacklisted domain identifier as stored in the data structure. In this manner, the security device may evaluate the source and / or destination network addresses and / or source and / or destination identifiers according to predefined rules or criteria, and perform actions based on the satisfaction of the rules and / or criteria. The criteria by which the security device analyzes incoming traffic to determine a match with a blacklisted domain and / or a network address of a device hosting a blacklisted domain may include, for example, a list of network addresses corresponding to the blacklisted domains contained in the data structure, a source identifier, a destination identifier, etc. In the event that the source network address, destination network address, and / or source or destination identifier of the incoming traffic matches the information stored in the data structure, an action may be performed. Example actions may include, for example, allowing traffic routing to be sent to an intended destination server device hosting a web page, sending (e.g., redirecting) traffic routing to a custom network address (e.g., a custom web page), sending traffic routing to a sinkhole server, resetting a connection (e.g., performing a TCP reset on the client device side and / or the server device side), sending a custom response code to the client device, and the like.

[0034] like Figure 1C As further shown in , and by reference numeral 130, the security device may selectively route traffic to a server device or a sinkhole server device based on comparing data contained in a packet header of the incoming traffic with information contained in the data structure. For example, in some implementations, the security device may determine that neither the source network address nor the destination network address corresponds to any network address contained in the data structure, and the traffic may be allowed. Additionally or alternatively, in the event that the security device determines that the source network address or the destination network address does correspond to the network address contained in the data structure, the traffic may be parsed to identify the domain name, such as in the event that the traffic is HTTP or HTTPS traffic. In some implementations, in the event that the domain name matches a blacklisted domain identifier, the traffic may be redirected to a sinkhole server associated with the blacklisted domain identifier. In this way, traffic sent to a network address of a device hosting a non-blacklisted domain may be allowed, while traffic sent to a network address of a device hosting a blacklisted domain may be blocked. For example, in some implementations, a device associated with a network address may host both non-blacklisted domains and blacklisted domains.

[0035] In some implementations, the security device may parse a header of one or more HTTP or HTTPS packets to determine a packet domain identifier, compare the packet domain identifier to a blacklisted domain identifier stored in a data structure, determine that the packet domain identifier corresponds to a blacklisted domain identifier stored in the data structure, and obtain a plurality of sinkhole server identifiers associated with the blacklisted domain identifier. The security device may select a sinkhole server identifier from the plurality of sinkhole server identifiers associated with the blacklisted domain identifier and redirect one or more packets to a sinkhole server associated with the sinkhole server identifier. In some implementations, the security device performs HTTP redirection of HTTP or HTTPS traffic, and destination NAT of non-HTTP and non-HTTPS traffic to redirect the traffic to a sinkhole server.

[0036] In some implementations, the security device may select a sinkhole server based on determining and selecting a sinkhole server that is closest to a client device that initiated or received the traffic. For example, the security device may execute a geographic proximity algorithm to select a sinkhole server that is closest to a client device that initiated or received the traffic. The security device may use a geographic proximity algorithm to identify a geographic location corresponding to a client device that initiated or received the traffic, identify multiple geographic locations corresponding to multiple sinkhole server identifiers, select a sinkhole server identifier associated with a sinkhole server that is geographically closest to the geographic location of the client device, and redirect the traffic to the sinkhole server associated with the selected sinkhole server identifier. In this manner, traffic can be redirected to a sinkhole server that is closest to the source of the traffic, which may be best equipped to log the traffic, report the traffic, and / or perform preventive actions on the traffic.

[0037] In some implementations, the security device may select a sinkhole server based on a round-robin scheduling process. For example, where the proximity of the sinkhole server and / or the client device may not be determined, the security device may select a sinkhole server in a round-robin manner. In this manner, traffic sent to the sinkhole server may be load balanced to prevent overloading the sinkhole server. In some implementations, load balancing and / or round-robin techniques may be used to direct traffic to a sinkhole server where the traffic is non-HTTP or non-HTTPS and / or where header parsing fails. In this manner, potential malicious attacks may be reduced or prevented.

[0038] In this manner, the devices described herein can improve security in public and / or private networks and utilize control plane devices (e.g., routing devices, security devices, etc.) to perform or implement DNS sinkhole functionality for directing traffic of an attacker or suspected attacker to a DNS sinkhole server for logging, reporting, and / or causing the execution of preventive actions. In this manner, traffic that bypasses traditional firewalls and / or security platforms that perform traditional DNS sinkhole functionality can be prevented from reaching devices in the network, and malicious attacks can be blocked, reduced, and / or avoided.

[0039] As mentioned above, Figure 1A-Figure 1C It is provided only as an example. Other examples are possible and can be compared with the Figure 1A-Figure 1C The examples described are different. For example, although Figure 1A-Figure 1C A component (e.g., a routing device, a security device, etc.) may be illustrated as performing one or more actions, but it should be understood that any component may perform one or more actions. The routing device and / or the security device may include a network device, one or both of which include control plane functionality by which the flow of traffic in the network may be controlled.

[0040] Figure 2A-2D is a diagram of an example implementation 200 described herein. Figure 2A-2D As shown in , an example implementation 200 may include a security platform that includes a DNS sinkhole data structure, a routing device, a forwarding component, a security device, and / or a client device. The routing device and / or the security device may include, alone or in combination, a threat assessment module as described herein, by which DNS data (e.g., blacklisted domain names, network addresses of suspected attackers, threat levels, etc.) may be obtained, evaluated, and used to generate a DNS response that sets a time-to-live value to zero. In some implementations, the routing device may include a firewall module as described herein, by which the forwarding component may be configured or directed to forward packets to the security device for inspection. The example implementation 200 may be provided in a public or private network provided by a network service provider.

[0041] like Figure 2A As shown in FIG. 1 and by reference numeral 202, a routing device may receive or obtain information from a security platform, including information stored in a DNS sinkhole data structure or database. As described above, the security platform may include a local or cloud-based security solution (e.g., including a firewall, etc.) configured to detect threats and implement DNS sinkhole functionality. In some implementations, aspects related to performing DNS sinkhole functionality may be implemented by the routing device and / or the security device using information received from the security platform.

[0042] In some implementations, the information obtained from the security platform may include, but is not limited to, a list of blacklisted domains (e.g., identified using blacklisted domain identifiers), a list of network address ranges or prefixes associated with possible or suspected attackers (e.g., suspicious IPv4 or IPv6 addresses, ranges, or prefixes), threat levels associated with the blacklisted domain identifiers and / or network address ranges or prefixes, one or more sinkhole server identifiers (e.g., sinkhole network addresses) to which traffic may be redirected if traffic is received from and / or sent to one or more blacklisted domain identifiers and / or network address ranges or prefixes, etc. This information may be stored (e.g., as threat data) in a data structure of and / or associated with the routing device and / or security device.

[0043] like Figure 2A As further shown in FIG. 1 and by reference numeral 204, a routing device using a firewall module can establish filters for incoming traffic. The filters can be established based on the type of traffic and / or the source or destination of the traffic as specified in a packet header of the traffic. For example, a filter can be used to forward all DNS traffic destined for port 53 to a security device. As another example, a filter can be used to forward traffic having a source identifier, source network address, destination identifier, or destination network address that matches a blacklisted domain identifier, network address, and / or source or destination identifier included in a data structure to a security device. Figure 2A As shown in FIG. 1 and by reference numeral 206, a filter may be installed on a forwarding component. In this manner, traffic received by a routing device from a suspected attacker may be forwarded to a security device for further inspection and evaluation.

[0044] like Figure 2AAs further shown in FIG. 1 and by reference numeral 208, a security device may create, establish, provide and / or otherwise be configured with a set of rules including matching criteria and actions performed based on satisfying the matching criteria. The rules may be used to detect and / or prevent possible attacks. For example, the rules may direct the security device to use information contained in a data structure as matching criteria for use when filtering traffic and performing actions based on the traffic. In some implementations, the security device may use a blacklisted domain identifier list, a network address list, a range, a prefix, etc. as a matching criterion for comparing or matching the domain identifier and / or network address of the incoming traffic as determined based on inspecting the packet header of the incoming traffic. The domain identifier and / or network address of the incoming traffic may be compared with the blacklisted domain identifier and / or network address obtained from the security platform and stored in the data structure for use when detecting traffic with a source identifier, source network address, destination identifier or destination network address that matches or corresponds to a blacklisted or suspicious entity (e.g., a device associated with a blacklisted domain identifier and / or suspicious network address, prefix or range).

[0045] In some implementations, the rules implemented by the security device may also include a threshold value, whereby a threat level associated with a blacklisted domain identifier and / or network address, range, and / or prefix stored in a data structure may be obtained and compared to the threshold value. The security device may perform one or more actions based on determining whether information associated with incoming traffic (e.g., packet header information) matches or corresponds to a blacklisted domain identifier and / or network address of a possible attacker stored in a data structure and / or whether the threat level associated with the blacklisted domain identifier and / or network address of the possible attacker meets a threshold value. Example actions include, for example, generating a DNS response and sending the DNS response to a client device from which traffic is received. The DNS response may include, for example, a time-to-live value set to zero. In this way, the client device may be unable to and / or blocked from caching the DNS response. Due to being blocked from caching the DNS response, the client device may be prevented from accessing the intended destination. In this way, a client device that may be a possible attacker may be prevented from bombarding a network device (e.g., a server, a sinkhole server, etc.) with requests and prohibiting the network device from running.

[0046] For example, the time-to-live value can specify a lifetime associated with DNS information received from a DNS server (e.g., a network address of a requested domain). Typically, client devices cache DNS information and use the stored information to resolve DNS requests before the record expires as specified by the time-to-live. Setting the time-to-live value to zero as described herein enables the DNS information to automatically expire upon reaching the client device and prevents the client device from caching the DNS information. In this way, the client device can be forced to initiate a new DNS request in an attempt to reach the network device. In some instances, the security device can monitor a count of DNS requests received from the client device to determine whether the client device is associated with an attacker based on the count satisfying a threshold.

[0047] like Figure 2B As shown in , and by reference numeral 210, a client device may send a DNS request to a routing device. The DNS request may include a destination domain associated with a destination domain identifier and a source network address corresponding to the client device from which the DNS request is received. As shown in reference numeral 212, the forwarding component may receive the DNS request. For example, the DNS request may be sent to and / or received by port 53 of the routing device, whereupon, as shown in reference numeral 214, the forwarding component may apply a previously installed filter and forward the DNS request to the security device for further evaluation and / or performance of one or more actions.

[0048] like Figure 2B As further shown in and by reference numeral 216, for example, based on rules implemented by the security device, the security device may compare data or information contained in the DNS request with information for blacklisted and / or suspicious domains or devices stored in a data structure. The security device may perform one or more actions based on the comparison of the information contained in the DNS request with the information stored in the data structure. In some implementations, the security device compares a domain identifier (e.g., a destination domain identifier) ​​contained or included in the DNS request with a blacklisted domain identifier stored in the data structure. Additionally or alternatively, in some implementations, the security device compares a source network address, range, and / or prefix (e.g., corresponding to a client device) contained in the DNS request with a network address, range, and / or prefix of a suspicious device stored in the data structure. In the event that the security device detects a match between a domain identifier and a blacklisted domain identifier and / or a source network address, range, and / or prefix and a network address, range, and / or prefix of a suspicious device, the security device may obtain and determine whether a threat level associated with the blacklisted domain identifier and / or network address, range, and / or prefix satisfies a threshold.

[0049] In some implementations, for example, where a domain identifier included in a DNS request matches a blacklisted domain identifier and a threat level associated with the blacklisted domain meets a threshold, the security device may actively sinkhole all DNS requests sent to the blacklisted domain identifier. For example, the security device may sinkhole the request by generating a DNS response and sending the DNS response to the client device, wherein the DNS response includes a time-to-live value set to zero. For example, where the threat level associated with the blacklisted domain meets a threshold, the domain identifier included in the DNS request matches the blacklisted domain identifier, and the network address, range, or prefix included in the DNS request matches the network address, range, or prefix of a suspected attacker stored in a data structure, the security device may sinkhole the DNS request. Additionally or alternatively, where the threat level associated with the blacklisted domain meets a threshold, the domain identifier included in the DNS request matches the blacklisted domain identifier, and the network address, range, or prefix included in the DNS request does not match the network address, range, or prefix of a suspected attacker stored in a data structure, the security device may still actively sinkhole the DNS request by generating a DNS response and sending the DNS response to the client device. The DNS response may include a time-to-live value set to zero and a sinkhole server identifier. In this manner, the security device may randomly sinkhole requests received from a client device having a non-suspicious source network address, range, or prefix, where, for example, the request is directed to a blacklisted domain, and where, for example, a threat level associated with the blacklisted domain meets a threshold.

[0050] like Figure 2C As shown in and by reference numeral 218, where a threshold for a threat level does not meet a threshold (e.g., a low threat level between 1-5 on a scale of 1-10), the security device may sinkhole DNS requests sent to a blacklisted domain identifier and a network address (or range or prefix) that matches the network address of a suspected attacker stored in a data structure. When the threshold is low, the security device may determine not to sinkhole DNS requests from a network address that does not match the network address of a suspected attacker stored in the data structure. When a sinkhole request is made, the security device may obtain a list of sinkhole server identifiers associated with the blacklisted domain identifier and / or the network address of the suspected attacker, select a sinkhole server identifier, generate a DNS response including the sinkhole server identifier, and respond to the DNS request with the DNS response. In some implementations, the DNS response includes a time-to-live value set to zero. In this way, suspicious and / or potentially malicious traffic from a client device is prevented from reaching an intended destination, which improves security in the network.

[0051] Additionally or alternatively, in the event that a threshold for the threat level is satisfied (e.g., a high threat level > 5 on a scale of 1-10) and for a request received from a source network address, range, or prefix that does not correspond to a network address, range, or prefix stored in a data structure, the security device may obtain a list of sinkhole server identifiers associated with a blacklisted domain identifier, select a sinkhole server identifier, generate a DNS response including the sinkhole server identifier, and respond to the DNS request with the DNS response. In some implementations, the DNS response includes a time-to-live value set to zero. In this manner, DNS requests received from random sources (which may be considered or classified as attackers as described herein) may be prevented from reaching devices in the network, and malicious attacks may be prevented. In some implementations, the threat level may be numerical or non-numerical. For purposes of illustration only, threat level 5 is selected as an example threshold based on a scale of 1-10. Other threat level values ​​and / or thresholds are contemplated.

[0052] like Figure 2C As shown in , and by reference numeral 220, a security device can respond to a DNS request from a client device. A DNS response generated and sent by the security device can include a network address associated with a sinkhole server and include a time to live (TTL) value set to zero. In this manner, a cache of a client device can be invalidated by a zero response time to live. In this manner, a client device can be prevented from caching DNS requests. A client device may be required to send multiple DNS requests in an attempt to reach an intended destination, and the security device can record and / or count the number of DNS requests received from a given client device when determining whether to deem or classify the client device as a possible attacker.

[0053] Figure 2D Various actions are illustrated based on monitoring a count of the number of DNS requests received from a client device after the client device sends a DNS response including a time-to-live value set to zero. Figure 2D As shown in , and by reference numeral 222, the security device can compile or configure a log of possible attackers based on monitoring a count of the number of requests received from the client device during a period of time. For example, in the event that the client device bombards the routing device with DNS requests such that the count of DNS requests meets a threshold, the security device can add the source network address of the client device to the list of possible attackers.

[0054] In this way, the security device can monitor the time-to-live value of the DNS response based on the

[0055] Set to zero to identify or detect possible attackers by counting the number of DNS requests caused.

[0056] like Figure 2D As further shown in the figure and by reference numeral 224, one or more filters can be installed on the forwarding component based on monitoring the count of DNS requests received from the client device. For example, in some implementations, in the event that the count of DNS requests received from the client device meets a threshold, the firewall module of the security device can install a filter on the forwarding component, through which the forwarding component can be directed to block or discard the DNS request received from the client device. In this way, traffic from the client device (which can be identified as a possible attacker based on the count of DNS requests received by the routing device) can be prevented from being routed and / or traversing the network and reaching devices in the network.

[0057] like Figure 2D As further shown in FIG. 1 , and by reference numeral 226, the routing device may send or report a possible attacker to the security platform. In some implementations, the security platform may include a cloud-based security platform, which in some cases corresponds to a global security device. For example, the routing device may send or report a network address associated with a client device that is considered a possible attacker based on monitoring the count of DNS requests received from the client device. In some implementations, the network address of the client device that satisfies the threshold count of DNS requests may be reported, transmitted, or sent to the security platform. The security platform may build a database (e.g., including a global attacker database) of network addresses of client devices that meet the threshold count of DNS requests. The database may be shared with additional global security devices for global blocking of the network address. In this way, a security enterprise that owns or operates a security platform may block potential attackers at a global level. In some implementations, the security platform includes a cloud-based security solution that hosts a global attacker database. The database may be shared with other security devices for global blocking of attackers or potential attackers with network addresses associated with client devices that meet the threshold count of DNS requests sent to the routing device.

[0058] In this manner, generating and sending a DNS response including a time-to-live value set to zero can be used to detect attackers based on logging and / or counting the number of DNS requests received from a given client device, and also prevent attacks by preventing the client device from reaching devices in the network. In this manner, sinkholing of random DNS requests based on the threat level of blacklisted domains or suspicious devices in the network also allows for inspection of a larger amount of traffic for further detection of possible attacks.

[0059] As indicated above, Figure 2A-2D It is provided only as an example. Other examples are possible and can be compared with the Figure 2A-2D The examples described are different. In addition, although Figure 1A-Figure 1C and Figure 2A-2D Different implementations are described, but some or all of the functionality of one implementation may be used in other implementations.

[0060] Figure 3 is a diagram of an example environment 300 in which the systems and / or methods described herein may be implemented. Figure 3 As shown in , environment 300 may include sinkhole server device 310, server device 320, client device 330, routing device 340, security device 350, cloud computing environment 360, security platform 370, computing resources 375, and network 380, as described herein. The devices of environment 300 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections.

[0061] The sinkhole server device 310 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information associated with blocking, detecting, and / or preventing malicious traffic. For example, the sinkhole server device 310 may include a server device or a group of server devices, a workstation computer or a group of workstation computers, a virtual machine (VM) or a group of virtual machines, etc., and the security device 350 may selectively route traffic (e.g., Internet traffic sent to the server device 320) to the above devices to prevent access to malicious content and capture, record, and / or analyze traffic to assess and contain threats (e.g., to the server device 320).

[0062] Server device 320 includes one or more devices capable of storing, processing, and / or transmitting information in a network. In some implementations, server device 320 is a network server that hosts a website. Server device 320 may include a communication interface that allows server device 320 to receive information from other devices in environment 300 and / or transmit information to other devices in environment 300. Server device 320 may include a blacklisted network server or a non-blacklisted network server as determined by security device 350, as described herein.

[0063] Client device 330 includes one or more devices capable of sending or receiving data (e.g., packets) such as Internet traffic. For example, client device 330 may include a communication and / or computing device such as a mobile phone (e.g., a smart phone, a wireless phone, etc.), a laptop computer, a tablet computer, a handheld computer, a gaming device, a wearable communication device (e.g., a smart watch, a pair of smart glasses, etc.), or a similar type of device. Client device 330 may send data to server device 320 via routing device 340 and via security device 350 in the form of Internet traffic monitored by security platform 370.

[0064] Routing device 340 includes one or more network devices (e.g., one or more traffic delivery devices) capable of processing and / or delivering traffic between endpoint devices. For example, routing device 340 may include a router, a firewall, a gateway, a switch, a hub, a bridge, a reverse proxy, a server (e.g., a proxy server), a security device, an intrusion detection device, a load balancer, or the like.

[0065] The security device 350 includes a network device such as a physical interface card (PIC) having a port that provides a physical connection to other elements in the network and can receive and send packets. Each physical port can be connected to one of many types of transport media, such as an optical fiber or Ethernet cable. A specific PIC and associated port can be programmed and formatted according to one of several protocols such as the synchronous optical network (SONET) standard, Ethernet or the Internet Protocol (IP). The security device 350 can be a modular and / or replaceable element of a network device (e.g., a routing device 340) and can be hot-pluggable, which means that the security device can be pulled out of its slot and replaced with a different PIC while the network device is operating without interrupting the operation of the network device. The security device 350 can perform data link layer functions, including using a data link layer protocol such as a point-to-point protocol (PPP) to communicate with another device. The security device 350 can perform operations on specific incoming (or outgoing) packets, such as decapsulation and encapsulation, classifying packets based on service categories, redirecting packets internally to other components of the network, managing flow tables, sampling packet flows, and the like. Security device 350 may be user-configurable for specific quality of service (QoS) requirements and may include a firewall.

[0066] Cloud computing environment 360 includes an environment for delivering computing as a service, whereby shared resources, services, etc. can be provided to sinkhole server device 310, server device 320, client device 330, routing device 340, security device 350, security platform 370, computing resources 375, etc. Cloud computing environment 360 can provide computing, software, data access, storage, and / or other services without requiring end users to know the physical location and configuration of the systems and / or devices delivering the services. As shown, cloud computing environment 360 can include security platform 370 and computing resources 375.

[0067] The security platform 370 includes a server device or similar device capable of receiving, generating, storing, processing, and / or providing information to the security device 350 for blocking, detecting, and / or preventing malicious traffic in the network. For example, the security platform 370 may be provided by a network service provider, a network operator, an enterprise, etc., which may globally monitor traffic (e.g., Internet traffic) for security purposes. In some implementations, as shown, the security platform 370 may be hosted in a cloud computing environment 360. It is worth noting that while the implementations described herein describe the security platform 370 as being hosted in a cloud computing environment 360, in some implementations, the security platform 370 may not be cloud-based (i.e., may be implemented outside of the cloud computing environment 360) or may be partially cloud-based.

[0068] The computing resources 375 include one or more personal computers, workstation computers, server devices, or another type of computing and / or communication devices. In some implementations, the computing resources 375 can host the security platform 370. Cloud resources can include computing instances executed in the computing resources 375, storage devices provided in the computing resources 375, data transfer devices provided by the computing resources 375, etc. In some implementations, the computing resources 375 can communicate with other computing resources 375 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0069] like Figure 3 As further shown in , the computing resources 375 may include a set of cloud resources, such as one or more applications ("APP") 375-1, one or more virtual machines ("VM") 375-2, virtualized storage devices ("VS") 375-3, one or more hypervisors ("HYP") 375-4, etc.

[0070] Applications 375-1 include one or more software applications that can be provided to or accessed by client devices 330, routing devices 340, and / or security devices 350. Applications 375-1 can eliminate the need to install and execute software applications on client devices 330, routing devices 340, and / or security devices 350. For example, applications 375-1 can include software associated with security platform 370 and / or any other software that can be provided via cloud computing environment 360. In some implementations, one application 375-1 can send / receive information to / from one or more other applications 375-1 via virtual machine 375-2.

[0071] Virtual machine 375-2 includes a software implementation of a machine (e.g., a computer, such as a physical machine) that executes a program. Virtual machine 375-2 can be a system virtual machine or a process virtual machine, depending on the use and degree of correspondence of virtual machine 375-2 to any real machine. System virtual machines can provide a complete system platform that supports the execution of a complete operating system ("OS"). Process virtual machines can execute a single program and can support a single process. In some implementations, virtual machine 375-2 can execute on behalf of a user (e.g., client device 330, routing device 340, and / or security device 350) and can manage the infrastructure of cloud computing environment 360, such as data management, synchronization, or long-term data transfer.

[0072] The virtualized storage device 375-3 includes one or more storage systems and / or one or more devices using virtualization technology within the storage system or device of the computing resource 375. In some implementations, in the context of the storage system, the types of virtualization may include block virtualization and file virtualization. Block virtualization may refer to the abstraction (or separation) of logical storage from physical storage, so that the storage system can be accessed without considering physical storage or heterogeneous structures. Separation may allow administrators of the storage system flexibility in how the administrator manages storage for end users. File virtualization may eliminate the dependency between data accessed at the file level and the location where the file is physically stored. This may enable optimization of storage usage, server consolidation, and / or non-disruptive file migration performance.

[0073] Hypervisor 375-4 provides hardware virtualization technology that allows multiple operating systems (e.g., "guest operating systems") to execute simultaneously on a host computer (such as computing resource 375). Hypervisor 375-4 can present a virtual operating platform to the guest operating system and can manage the execution of the guest operating system. Multiple instances of various operating systems can share virtualized hardware resources.

[0074] The network 380 includes one or more wired and / or wireless networks. For example, the network 380 may include a communication network, a cellular network (e.g., a long-term evolution (LTE) network, a code division multiple access (CDMA) network, a 3G network, a 4G network, a 5G network, another type of next-generation network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a public switched telephone network (PSTN)), a public network, a private network, an ad hoc network, an intranet, the Internet, a fiber-optic-based network, a cloud computing network, etc., and / or a combination of these or other types of networks.

[0075] In some implementations, routing device 340 and / or security device 350 may be physical devices implemented within a housing such as a chassis. In some implementations, routing device 340 and / or security device 350 may be virtual devices implemented by one or more computer devices in a cloud computing environment or data center.

[0076] supply Figure 3 The number and arrangement of devices and networks shown in the figure are examples. Figure 3 There may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or differently arranged devices and / or networks than those shown in FIG. Figure 3 Two or more of the devices shown in may be implemented in a single device, or Figure 3 The single device shown in the environment 300 may be implemented as multiple distributed devices. Additionally or alternatively, a set of devices (eg, one or more devices) of the environment 300 may perform one or more functions described as being performed by another set of devices of the environment 300.

[0077] Figure 4A-4B is a diagram of example components of devices 400 and 425. Devices 400 and 425 may correspond to sinkhole server device 310, server device 320, client device 330, routing device 340, security device 350, security platform 370, and / or computing resource 375. In some implementations, sinkhole server device 310, server device 320, client device 330, routing device 340, security device 350, security platform 370, and / or computing resource 375 may include one or more devices 400, one or more devices 425, one or more components of device 400, and / or one or more components of device 425. Figure 4A As shown in , the device 400 may include an input component 405, a switching component 410, an output component 415, and a controller 420. Figure 4B As shown in , device 425 may include a bus 430 , a processor 435 , a memory 440 , a storage component 445 , an input component 450 , an output component 455 , and a communication interface 460 .

[0078] Figure 4A 4 is a diagram of example components of device 400. Device 400 may correspond to routing device 340 and / or security device 350. In some implementations, routing device 340 and / or security device 350 may include one or more devices 400 and / or one or more components of device 400. Figure 4AAs shown in , the device 400 may include one or more input components 405-1 to 405-B (B≥1) (hereinafter collectively referred to as input component 405, and individually referred to as input component 405), a switching component 410, one or more output components 415-1 to 415-C (C≥1) (hereinafter collectively referred to as output component 415, and individually referred to as output component 415), and a controller 420.

[0079] The input component 405 can be an attachment point for a physical link and can be an entry point for incoming traffic such as packets. The input component 405 can process incoming traffic, such as by performing data link layer encapsulation or decapsulation. In some implementations, the input component 405 can send and / or receive packets. In some implementations, the input component 405 may include an input line card, which includes one or more packet processing components (e.g., in the form of an integrated circuit), such as one or more interface cards (IFCs), packet forwarding components, line card controller components, input ports, processors, memory, and / or input queues. In some implementations, the device 400 may include one or more input components 405.

[0080] The switching component 410 can interconnect the input component 405 with the output component 415. In some implementations, the switching component 410 can be implemented via one or more crossbar switches, via a bus, and / or using a shared memory. The shared memory can act as a temporary buffer to store packets from the input component 405 before the packets are finally scheduled for delivery to the output component 415. In some implementations, the switching component 410 can enable the input component 405, the output component 415, and / or the controller 420 to communicate.

[0081] The output component 415 can store packets and can schedule packets for transmission on an output physical link. The output component 415 can support data link layer encapsulation or decapsulation, and / or various higher-level protocols. In some implementations, the output component 415 can send packets and / or receive packets. In some implementations, the output component 415 may include an output line card, which includes one or more packet processing components (e.g., in the form of an integrated circuit), such as one or more IFCs, packet forwarding components, line card controller components, output ports, processors, memories, and / or output queues. In some implementations, the device 400 may include one or more output components 415. In some implementations, the input component 405 and the output component 415 can be implemented by the same set of components (e.g., and the input / output component can be a combination of the input component 405 and the output component 415).

[0082] The controller 420 includes a processor in the form of, for example, a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), and / or another type of processor. The processor is implemented in hardware, firmware, or a combination of hardware and software. In some implementations, the controller 420 may include one or more processors that can be programmed to perform a function.

[0083] In some implementations, the controller 420 may include random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic storage, optical storage, etc.) that stores information and / or instructions for use by the controller 420.

[0084] In some implementations, the controller 420 can communicate with other devices, networks, and / or systems connected to the device 400 to exchange information about the network topology. The controller 420 can create a routing table based on the network topology information, create a forwarding table based on the routing table, and forward the forwarding table to the input component 405 and / or the output component 415. The input component 405 and / or the output component 415 can use the forwarding table to perform a route lookup for incoming and / or outgoing packets.

[0085] The controller 420 may perform one or more processes described herein. The controller 420 may perform these processes in response to executing software instructions stored by a non-transient computer readable medium. A computer readable medium is defined herein as a non-transient memory device. A memory device includes a memory space within a single physical storage device or a memory space across multiple physical storage devices.

[0086] The software instructions may be read from another device or from another computer-readable medium via a communication interface into a memory and / or storage component associated with the controller 420. When executed, the software instructions stored in the memory and / or storage component associated with the controller 420 may cause the controller 420 to perform one or more processes described herein. Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, the implementations described herein are not limited to any specific combination of hardware circuitry and software.

[0087] supply Figure 4A The number and arrangement of components shown in FIG. are provided as examples. Figure 4ADevice 400 may include additional components, fewer components, different components, or differently arranged components than those shown in . Additionally or alternatively, a set of components (e.g., one or more components) of device 400 may perform one or more functions described as being performed by another set of components of device 400.

[0088] Figure 4B 4 is a diagram of example components of device 425. Device 425 may correspond to routing device 340 and / or security device 350. In some implementations, routing device 340 and / or security device 350 may include one or more devices 425 and / or one or more components of device 425. Figure 4B As shown in , device 425 may include a bus 430 , a processor 435 , a memory 440 , a storage component 445 , an input component 450 , an output component 455 , and a communication interface 460 .

[0089] Bus 430 includes components that allow communication between components of device 400. Processor 435 is implemented in hardware, firmware, or a combination of hardware and software. Processor 435 takes the form of a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or another type of processing component. In some implementations, processor 435 includes one or more processors that can be programmed to perform functions. Memory 440 includes random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions for use by processor 435.

[0090] Storage component 445 stores information and / or software related to the operation and use of device 400. For example, storage component 445 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, and / or a solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cassette, a magnetic tape, and / or another type of non-transitory computer-readable medium and a corresponding drive.

[0091] Input components 450 include components that allow device 400 to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone). Additionally or alternatively, input components 450 may include sensors for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). Output components 455 include components that provide output information from device 400 (e.g., a display, a speaker, and / or one or more light emitting diodes (LEDs)).

[0092] The communication interface 460 includes a transceiver-like component (e.g., a transceiver and / or a separate receiver and transmitter) that enables the device 400 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of a wired and wireless connection. The communication interface 460 can allow the device 400 to receive information from another device and / or provide information to another device. For example, the communication interface 460 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, etc.

[0093] Device 425 can perform one or more processes described herein. Device 400 can perform these processes based on processor 435 executing software instructions stored by non-transient computer-readable media (such as memory 440 and / or storage component 445). Computer-readable media is defined as non-transient memory devices in this article. Memory devices include memory space within a single physical storage device or memory space across multiple physical storage devices.

[0094] The software instructions may be read from another computer-readable medium or from another device into the memory 440 and / or storage component 445 via the communication interface 460. When executed, the software instructions stored in the memory 440 and / or storage component 445 may cause the processor 435 to perform one or more processes described herein. Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, the implementations described herein are not limited to any specific combination of hardware circuitry and software.

[0095] supply Figure 4B The number and arrangement of components shown in FIG. are provided as examples. Figure 4B Device 425 may include additional components, fewer components, different components, or differently arranged components than those shown in . Additionally or alternatively, a set of components (e.g., one or more components) of device 425 may perform one or more functions described as being performed by another set of components of device 425.

[0096] Figure 5 is a flow chart of an example process 500 for blocking, detecting, and / or preventing malicious traffic. In some implementations, Figure 5 One or more process blocks of may be performed by a security device (e.g., security device 350). In some implementations, Figure 5One or more processing blocks may be performed by another device or a group of devices separate from or including the security device (e.g., security device 350), such as a sinkhole server device (e.g., sinkhole server device 310), a client device (e.g., client device 330), a routing device (e.g., routing device 340), a security platform (e.g., security platform 370), and / or a computing resource of a cloud computing environment (e.g., computing resource 375).

[0097] like Figure 5 As shown in , process 500 may include obtaining information associated with a plurality of blacklisted domains, wherein the information includes a blacklisted domain identifier corresponding to a blacklisted domain in the plurality of blacklisted domains (block 510). For example, a security device (e.g., using input component 405, switch component 410, controller 420, processor 435, memory 440, storage component 445, input component 450, communication interface 460, etc.) may obtain information associated with a plurality of blacklisted domains, as described above in conjunction with Figure 1A-Figure 1C In some implementations, the information may include a blacklisted domain identifier corresponding to a blacklisted domain in the plurality of blacklisted domains.

[0098] like Figure 5 As further shown in FIG. 5 , process 500 may include determining a network address of a device hosting a plurality of blacklisted domains based on collecting domain name system (DNS) data associated with the blacklisted domain identifiers (block 520). For example, the security device (e.g., using input component 405, switch component 410, controller 420, processor 435, memory 440, storage component 445, input component 450, communication interface 460, etc.) may determine a network address of a device hosting a plurality of blacklisted domains based on collecting domain name system (DNS) data associated with the blacklisted domain identifiers, as described above in conjunction with Figure 1A-Figure 1C described.

[0099] like Figure 5 As further shown in FIG. 5 , process 500 may include storing a network address of a device hosting a plurality of blacklisted domains and a blacklisted domain identifier (block 530). For example, a security device (e.g., using controller 420, processor 435, memory 440, storage component 445, etc.) may store a network address of a device hosting a plurality of blacklisted domains and a blacklisted domain identifier, as described above in connection with Figure 1A-Figure 1C described.

[0100] like Figure 5As further shown in FIG. 5 , process 500 may include receiving traffic destined for a destination device associated with a destination network address (block 540). For example, a security device (e.g., using input component 405, switch component 410, controller 420, processor 435, memory 440, storage component 445, input component 450, communication interface 460, etc.) may receive one or more destination packets destined for a destination device associated with a destination network address, as described above in conjunction with Figure 1A-Figure 1C described.

[0101] like Figure 5 As further shown in FIG. 5 , process 500 may include comparing the destination network address to the network address stored in the data structure (block 550). For example, the security device (e.g., using controller 420, processor 435, memory 440, storage component 445, etc.) may compare the destination network address to the network address stored in the data structure, as described above in conjunction with Figure 1A-Figure 1C described.

[0102] like Figure 5 As further shown in FIG. 5 , process 500 may include performing an action based on the result of comparing the destination network address with the network address (block 560). For example, the security device (e.g., using switching component 410, output component 415, controller 420, processor 435, memory 440, storage component 445, input component 450, output component 455, communication interface 460, etc.) may perform an action based on the result of comparing the destination network address with the network address, as described above in conjunction with Figure 1A-Figure 1C described.

[0103] Process 500 may include additional implementations, such as any single implementation or any combination of implementations described below and / or described with respect to any other process described herein.

[0104] In some implementations, the action can include determining that the destination network address does not correspond to any of the network addresses, and routing the one or more packets toward the destination device based on determining that the destination network address does not correspond to any of the network addresses.

[0105] In some implementations, the actions can include determining that the destination network address corresponds to the network address of the network address, determining that the traffic corresponds to HTTP traffic, parsing a header of the HTTP traffic to determine a packet domain identifier, comparing the packet domain identifier to a blacklisted domain identifier stored in a data structure, determining that the packet domain identifier corresponds to the blacklisted domain identifier stored in the data structure, obtaining a plurality of sinkhole server identifiers associated with the blacklisted domain identifier, selecting a sinkhole server identifier from the plurality of sinkhole server identifiers associated with the blacklisted domain identifier, and redirecting the HTTP traffic toward the sinkhole server HTTP identifier associated with the sinkhole server identifier.

[0106] In some implementations, when selecting a sinkhole server identifier, the security device may identify a first geographic location corresponding to a client device from which one or more packets are received, may identify multiple second geographic locations corresponding to multiple sinkhole server identifiers, and may select a sinkhole server identifier associated with a sinkhole server that is geographically closest to the first geographic location. In some implementations, when selecting a sinkhole server identifier, the security device may select the sinkhole server identifier based on a round-robin scheduling process.

[0107] In some implementations, the actions can include determining that the destination network address corresponds to a network address in the network address, determining that the network address corresponds to a blacklisted domain identifier, determining that the traffic corresponds to non-HTTP traffic, obtaining a plurality of sinkhole server identifiers associated with the blacklisted domain identifier, selecting a sinkhole server identifier from the plurality of sinkhole server identifiers associated with the blacklisted domain identifier, and performing network address translation (NAT) of the non-HTTP traffic by replacing the destination network address in the non-HTTP traffic with the sinkhole server identifier to redirect one or more packets toward a sinkhole server associated with the sinkhole server identifier.

[0108] In some implementations, when determining the network address, the security device may generate a DNS request including the blacklisted domain identifier, may send the DNS request to a DNS server, and may receive a response to the DNS request from the DNS server. In some implementations, the response may include the network address of the device hosting the plurality of blacklisted domains. In some implementations, the security device may cache the network address included in the response to the DNS request.

[0109] In some implementations, when determining the network address, the security device can intercept DNS messages exchanged between the DNS resolver device and the DNS server device. In some implementations, the DNS message can include the network address of the device hosting the plurality of blacklisted domains. In some implementations, the security device can cache the network address included in the DNS message.

[0110] although Figure 5 Example blocks of process 500 are shown, but in some implementations, Figure 5 Process 500 may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in FIG. Additionally or alternatively, two or more blocks of process 500 may be performed in parallel.

[0111] Figure 6 is a flow chart of an example process 600 for blocking, detecting, and / or preventing malicious traffic. In some implementations, Figure 6 One or more process blocks of may be performed by a security device (e.g., security device 350). In some implementations, Figure 6 One or more process blocks may be performed by another device or a group of devices separate from or including the security device (e.g., security device 350), such as a sinkhole server device (e.g., sinkhole server device 310), a client device (e.g., client device 330), a routing device (e.g., routing device 340), a security device (e.g., security device 350), a security platform (e.g., security platform 370), and / or a computing resource of a cloud computing environment (e.g., computing resource 375).

[0112] like Figure 6 As shown in , process 600 may include obtaining information associated with a plurality of blacklisted domains, wherein the information includes a blacklisted domain identifier corresponding to a blacklisted domain in the plurality of blacklisted domains (block 610). For example, a security device (e.g., using input component 405, switch component 410, controller 420, processor 435, memory 440, storage component 445, input component 450, communication interface 460, etc.) may obtain information associated with a plurality of blacklisted domains, as described above in conjunction with Figure 2A-2D In some implementations, the information may include a blacklisted domain identifier corresponding to a blacklisted domain in the plurality of blacklisted domains.

[0113] like Figure 6As further shown in FIG. 6 , process 600 may include obtaining a plurality of source network address prefixes, wherein a source network address prefix in the plurality of source network address prefixes is associated with a possible attacker (block 620). For example, the security device (e.g., using input component 405, switch component 410, controller 420, processor 435, memory 440, storage component 445, input component 450, communication interface 460, etc.) may obtain a plurality of source network address prefixes, as described above in conjunction with Figure 2A-2D In some implementations, a source network address prefix in the plurality of source network address prefixes can be associated with a possible attacker.

[0114] like Figure 6 As further shown in FIG. 6 , process 600 may include receiving a domain name system (DNS) request, wherein the DNS request includes a request to access a destination domain associated with a destination domain identifier, and a source network address corresponding to a device from which the DNS request is received (block 630). For example, a security device (e.g., using input component 405, switching component 410, controller 420, processor 435, memory 440, storage component 445, input component 450, communication interface 460, etc.) may receive a domain name system (DNS) request, as described above in conjunction with Figure 2A-2D In some implementations, the DNS request can include a request to access a destination domain associated with a destination domain identifier, and a source network address corresponding to a device from which the DNS request was received.

[0115] like Figure 6 As further shown in FIG. 6 , process 600 may include determining that the destination domain identifier corresponds to a blacklisted domain identifier among the blacklisted domain identifiers (block 640). For example, the security device (e.g., using controller 420, processor 435, memory 440, storage component 445, etc.) may determine that the destination domain identifier corresponds to a blacklisted domain identifier among the blacklisted domain identifiers, as described above in conjunction with Figure 2A-2D described.

[0116] like Figure 6 As further shown in FIG. 6 , process 600 may include obtaining a threat level associated with a blacklisted domain identifier (block 650). For example, the security device (e.g., using input component 405, switch component 410, controller 420, processor 435, memory 440, storage component 445, input component 450, communication interface 460, etc.) may obtain a threat level associated with a blacklisted domain identifier, as described above in conjunction with Figure 2A-2D described.

[0117] like Figure 6As further shown in FIG. 6 , process 600 may include determining whether a threat level associated with a blacklisted domain identifier satisfies a threshold (block 660). For example, the security device (e.g., using controller 420, processor 435, memory 440, storage component 445, etc.) may determine whether a threat level associated with a blacklisted domain identifier satisfies a threshold, as described above in conjunction with Figure 2A-2D described.

[0118] like Figure 6 As further shown in FIG. 6 , process 600 may include comparing the prefix of the source network address to multiple source network address prefixes (block 670). For example, the security device (e.g., using controller 420, processor 435, memory 440, storage component 445, etc.) may compare the prefix of the source network address to multiple source network address prefixes, as described above in conjunction with Figure 2A-2D described.

[0119] like Figure 6 As further shown in FIG. 6 , process 600 may include performing an action based on the result of whether the threat level associated with the blacklisted domain identifier meets the threshold and the result of comparing the prefix of the source network address with the plurality of source network address prefixes (block 680). For example, the security device (e.g., using input component 405, switch component 410, output component 415, controller 420, processor 435, memory 440, storage component 445, input component 450, output component 455, communication interface 460, etc.) may perform an action based on the result of whether the threat level associated with the blacklisted domain identifier meets the threshold and the result of comparing the prefix of the source network address with the plurality of source network address prefixes, as described above in conjunction with Figure 2A-2D described.

[0120] Process 600 may include additional implementations, such as any single implementation or any combination of implementations described below and / or described with respect to any other process described herein.

[0121] In some implementations, the actions may include determining that a prefix of the source network address corresponds to a source network address prefix of a plurality of source network address prefixes, obtaining a plurality of sinkhole server identifiers associated with the source network address prefix, selecting a sinkhole server identifier from the plurality of sinkhole server identifiers associated with the source network address prefix, generating a DNS response including the sinkhole server identifier, and responding to the DNS request with the DNS response. In some implementations, the DNS response may include a time-to-live value set to zero.

[0122] In some implementations, the actions may include determining that a prefix of the source network address does not correspond to any of a plurality of source network address prefixes, determining that a threat level associated with a blacklisted domain identifier satisfies a threshold, obtaining a plurality of sinkhole server identifiers associated with the blacklisted domain identifier, selecting a sinkhole server identifier from the plurality of sinkhole server identifiers associated with the blacklisted domain identifier, generating a DNS response including the sinkhole server identifier, and responding to the DNS request with the DNS response. In some implementations, the DNS response includes a time-to-live value set to zero.

[0123] In some implementations, the security device may add the source network address of the device from which the DNS request is received to a list of possible attackers and monitor the count of DNS requests received from the source network address. In some implementations, when the count of DNS requests meets a threshold, the security device may block the DNS request received from the source network address. In some implementations, when the count of DNS requests meets the threshold, the security device may report the source network address to the cloud-based security platform. The cloud-based security platform may build a global attacker database including the source network address and share the global attacker database with at least one other cloud-based security platform for globally blocking attackers.

[0124] In some implementations, Figure 6 One or more process blocks of may be performed by a processor or controller (e.g., processor 435 or controller 420). In some implementations, the processor may be disposed in a routing device (e.g., routing device 340) or in a security device (e.g., security device 350) attached to the routing device.

[0125] although Figure 6 Example blocks of process 600 are shown, but in some implementations, Figure 6 Process 600 may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in FIG. Additionally or alternatively, two or more blocks of process 600 may be performed in parallel.

[0126] Figure 7 is a flow chart of an example process 700 for blocking, detecting, and / or preventing malicious traffic. In some implementations, Figure 7 One or more process blocks of may be performed by a network device such as a security device (e.g., security device 350) and / or a routing device (e.g., routing device 340). In some implementations, Figure 7One or more process blocks may be performed by another device or a group of devices that is separate from or includes a network device (e.g., security device 350 and / or routing device 340), such as a sinkhole server device (e.g., sinkhole server device 310), a client device (e.g., client device 330), a security platform (e.g., security platform 370), and computing resources of a cloud computing environment (e.g., computing resources 375).

[0127] like Figure 7 As shown in , process 700 may include obtaining information associated with a plurality of blacklisted domains, wherein the information includes blacklisted domain identifiers and sinkhole server identifiers associated with the blacklisted domain identifiers (block 710). For example, a security device (e.g., using input component 405, switch component 410, controller 420, processor 435, memory 440, storage component 445, input component 450, communication interface 460, etc.) may obtain information associated with a plurality of blacklisted domains, as described above in conjunction with Figure 1A-Figure 2D In some implementations, the information may include a blacklisted domain identifier and a sinkhole server identifier associated with the blacklisted domain identifier.

[0128] like Figure 7 As further shown in FIG. 7 , process 700 may include obtaining a set of rules, wherein the set of rules specifies matching criteria associated with a plurality of blacklisted domains, wherein the matching criteria include a plurality of source network addresses and / or a plurality of destination network addresses for comparison with a packet source network address and / or a packet destination network address associated with an incoming packet, and wherein the set of rules specifies an action to be performed based on a result of comparing the matching criteria with the packet source network address and / or the packet destination network address for the incoming packet (block 720). For example, a security device (e.g., using input component 405, switch component 410, controller 420, processor 435, memory 440, storage component 445, input component 450, communication interface 460, etc.) may obtain a set of rules, as described above in conjunction with Figure 1A-Figure 2D In some implementations, the set of rules may specify matching criteria associated with a plurality of blacklisted domains, the matching criteria may include a plurality of source network addresses and / or a plurality of destination network addresses for comparison with a packet source network address and / or a packet destination network address associated with an incoming packet, and the set of rules may specify an action to be performed based on a result of comparing the matching criteria with the packet source network address and / or the packet destination network address for the incoming packet.

[0129] like Figure 7As further shown in FIG. 7 , process 700 may include receiving one or more packets (block 730). For example, a security device (e.g., using input component 405, switch component 410, controller 420, processor 435, memory 440, storage component 445, input component 450, communication interface 460, etc.) may receive one or more packets, as described above in conjunction with Figure 1A-Figure 2D described.

[0130] like Figure 7 As further shown in FIG. 7 , process 700 may include checking a packet source network address and / or a packet destination network address associated with one or more packets (block 740). For example, a security device (e.g., switch component 410, controller 420, processor 435, memory 440, storage component 445, communication interface 460, etc.) may check a packet source network address and / or a packet destination network address associated with one or more packets, as described above in conjunction with Figure 1A-Figure 2D described.

[0131] like Figure 7 As further shown in FIG. 7 , process 700 may include comparing the packet source network address and / or the packet destination network address to the matching criteria (block 750). For example, the security device (e.g., using controller 420, processor 435, memory 440, storage component 445, etc.) may compare the packet source network address and / or the packet destination network address to the matching criteria, as described above in conjunction with Figure 1A-Figure 2D described.

[0132] like Figure 7 As further shown in FIG. 7 , process 700 may include performing an action based on a result of comparing a packet source network address and / or a packet destination network address with a matching criterion specified by the set of rules (block 760). For example, a security device (e.g., using input component 405, switch component 410, output component 415, controller 420, processor 435, memory 440, storage component 445, input component 450, output component 455, communication interface 460, etc.) may perform an action based on a result of comparing a packet source network address and / or a packet destination network address with a matching criterion specified by the set of rules, as described above in conjunction with Figure 1A-Figure 2D described.

[0133] Process 700 may include additional implementations, such as any single implementation or any combination of implementations described below and / or described with respect to any other process described herein.

[0134] In some implementations, the security device can determine that the packet destination network address satisfies the matching criteria, determine that the packet destination network address corresponds to an address of a blacklisted domain identifier, select a sinkhole server identifier associated with the blacklisted domain identifier, and send one or more packet routes to the sinkhole server associated with the sinkhole server identifier.

[0135] In some implementations, the security device may identify a first geographic location corresponding to a device having a source network address of the packet, identify multiple second geographic locations corresponding to multiple sinkhole server identifiers associated with blacklisted domain identifiers, and select a sinkhole server identifier associated with a sinkhole server having a second geographic location that is geographically closest to the first geographic location.

[0136] In some implementations, the security device may select a sinkhole server identifier based on a round-robin scheduling process. In some implementations, the security device may determine that a packet source network address satisfies a matching criterion, obtain a plurality of sinkhole server identifiers associated with the packet source network address, select the sinkhole server identifier from the plurality of sinkhole server identifiers, generate a message including the sinkhole server identifier, and send the message to a device corresponding to the packet source network address. In some implementations, the message includes a domain name system (DNS) response having a time-to-live value set to zero.

[0137] although Figure 7 Example blocks of process 700 are shown, but in some implementations, Figure 7 Process 700 may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in FIG. Additionally or alternatively, two or more blocks of process 700 may be performed in parallel.

[0138] Some implementations described herein include a network device including a security device 350 configured to block, detect, and / or prevent malicious traffic in a network 380. The security device 350 may be implemented as a network device (e.g., a routing device 340, etc.) and / or a security device 350 attached to a network device (e.g., a physical interface card of a routing device 340, etc.). In some implementations, the security device 350 may block malicious traffic in a network 380. For example, a country or customer may specify a list of blacklisted domains that the country or customer wishes to block users from accessing. As an example, a blacklisted domain may be associated with an attacker device or an attacker's website. In some implementations, the security device 350 may be configured to actively perform mining techniques to resolve network addresses for devices hosting blacklisted domains. The security device 350 may utilize matching criteria included in a matching filter and / or rule to block traffic sent to the resolved network address. For example, the security device 350 may block traffic sent to a network address associated with a network server hosting a blacklisted domain and redirect the traffic toward a sinkhole server device 310. In this way, network security can be improved due to more effective blocking of malicious traffic and / or access to malicious content. In addition, traffic from attackers that bypass DNS sinkhole functionality can be blocked, logged, and / or prevented from accessing intended destinations.

[0139] In some implementations, the security device 350 can detect malicious traffic in the network 380 and / or prevent the malicious traffic from reaching other devices in the network 380 (e.g., server devices, sinkhole server devices, etc.). For example, the security device 350 can receive a DNS request, determine that the DNS request is associated with a possible attacker, and respond to the DNS request with a DNS response that includes a time-to-live value set to zero. In this way, the DNS response may not be cached by the possible attacker, so that subsequent DNS requests from the same source network address can be logged and investigated. In the event that the source device is identified as an attacker, the security device can notify the cloud-based security platform so that the attacker can be blocked globally. In this way, security on one or more networks can be improved because the attacker can be elegantly identified and prevented from reaching back-end devices in one or more networks.

[0140] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of these implementations.

[0141] As used herein, the term component is intended to be broadly interpreted as hardware, firmware, and / or a combination of hardware and software.

[0142] As used herein, the term traffic or content may include a group of packets. A packet may refer to a communication structure for transmitting information, such as a protocol data unit (PDU), a network packet, a datagram, a segment, a message, a block, a cell, a frame, a subframe, a time slot, a symbol, any portion of the above, and / or another type of formatted or unformatted data unit capable of being transmitted via a network.

[0143] Some implementations are described herein in conjunction with thresholds. As used herein, satisfying a threshold may refer to a value being greater than a threshold, more than a threshold, above a threshold, greater than or equal to a threshold, less than a threshold, less than a threshold, below a threshold, less than or equal to a threshold, equal to a threshold, etc.

[0144] It is apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit the implementation. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software code - it should be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0145] Even though particular combinations of features are stated in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features may be combined in ways not specifically stated in the claims and / or disclosed in the specification. Although each of the dependent claims listed below may directly depend on only one claim, the disclosure of possible implementations includes the combination of each dependent claim with every other claim in the claim set.

[0146] Unless so clearly described, the elements, actions or instructions used herein should not be interpreted as being critical or necessary. In addition, as used herein, the articles "one" and "an" are intended to include one or more projects, and can be used interchangeably with "one or more". In addition, as used herein, the term "set" is intended to include one or more projects (e.g., related projects, unrelated projects, combinations of related projects and unrelated projects, etc.), and can be used interchangeably with "one or more". In the case of only one project, the term "one" or similar language is used. In addition, as used herein, the terms "has", "have", "having" etc. are intended to be open terms. In addition, unless otherwise expressly stated, the phrase "based on" is intended to mean "based at least in part on".

Claims

1. A method for redirecting traffic, include: storing, by the processor, in a data structure a network address of a device hosting a plurality of blacklisted domains and a plurality of blacklisted domain identifiers corresponding to the plurality of blacklisted domains; receiving, by the processor, traffic destined for a destination device associated with a destination network address; determining, by the processor, that the destination network address corresponds to a network address among the network addresses stored in the data structure; determining, by the processor, based on determining that the destination network address corresponds to the network address, that the network address corresponds to a blacklisted domain identifier of the plurality of blacklisted domain identifiers and that a threat level associated with the blacklisted domain identifier satisfies a threshold; selecting, by the processor, a sinkhole server identifier from a plurality of sinkhole server identifiers associated with the blacklisted domain identifier based on the threat level, The sinkhole server identifier is selected based on: geographic proximity to the location of the client device, or Cyclic scheduling process; as well as The traffic is redirected, by the processor, toward a sinkhole server associated with the sinkhole server identifier.

2. The method of claim 1, wherein the sinkhole server identifier is selected include: A geographic proximity algorithm is executed to select the sinkhole server that is closest to the location of the client device.

3. The method of claim 1, wherein the sinkhole server identifier is selected include: identifying a first geographic location corresponding to the client device from which the traffic is received; identifying a plurality of second geographic locations corresponding to the plurality of sinkhole server identifiers; and Wherein selecting the sinkhole server identifier comprises: The sinkhole server identifier associated with the sinkhole server that is geographically closest to the first geographic location is selected.

4. The method of claim 1, wherein the sinkhole server identifier is selected include: When the geographic proximity to the location of the client device cannot be determined, multiple sinkhole servers are load balanced via the round-robin scheduling process.

5. The method according to claim 1, further comprising: include: determining that a packet source network address satisfies matching criteria associated with the plurality of blacklisted domains; generating a message including the sinkhole server identifier; as well as sending the message to a device corresponding to the packet source network address, Wherein the message comprises a Domain Name System (DNS) response having a time-to-live value set to zero.

6. The method according to claim 1, further comprising: include: generating a DNS request including the plurality of blacklisted domain identifiers; Sending the DNS request to a DNS server; receiving a response to the DNS request from the DNS server, wherein the response includes the network address of the device hosting the plurality of blacklisted domains; as well as The network address included in the response to the DNS request is cached.

7. The method according to claim 1, further comprising: include: Intercept DNS messages exchanged between DNS resolver devices and DNS server devices, wherein the DNS message includes the network address of a device hosting the plurality of blacklisted domains; and The network address included in the DNS message is cached.

8. A network device, include: one or more memories; as well as One or more processors, communicatively coupled to the one or more memories, the one or more processors configured to: storing in a data structure a network address of a device hosting a plurality of blacklisted domains and a plurality of blacklisted domain identifiers corresponding to the plurality of blacklisted domains; receiving traffic destined for a destination device associated with a destination network address; based on determining that the destination network address corresponds to a network address among the network addresses of a device, determining that the network address corresponds to a blacklisted domain identifier and that a threat level associated with the blacklisted domain identifier satisfies a threshold; selecting a sinkhole server identifier from a plurality of sinkhole server identifiers associated with the blacklisted domain identifier corresponding to the network address based on the threat level, The sinkhole server identifier is selected based on: geographic proximity to the location of the client device, or Cyclic scheduling process; as well as The traffic is redirected toward a sinkhole server associated with the sinkhole server identifier.

9. The network device of claim 8, wherein the one or more processors are further configured to: establishing a filter based on the network address of the device hosting the plurality of blacklisted domains; and The filter is installed on a forwarding component associated with the network device.

10. The network device of claim 8, wherein the one or more processors are further configured to: Determining that the traffic corresponds to Hypertext Transfer Protocol (HTTP) traffic; Parse the header of HTTP traffic to determine the domain identifier; comparing the domain identifier to the plurality of blacklisted domain identifiers stored in the data structure; determining that the domain identifier corresponds to a blacklisted domain identifier of the plurality of blacklisted domain identifiers; wherein the one or more processors, when selecting the sinkhole server identifier, are configured to: selecting the sinkhole server identifier based on determining that the domain identifier corresponds to the blacklisted domain identifier; and wherein the one or more processors, when redirecting the traffic toward the sinkhole server, are configured to: The HTTP traffic is HTTP redirected toward the sinkhole server associated with the sinkhole server identifier.

11. The network device of claim 9, wherein the one or more processors are further configured to: identifying a first geographic location corresponding to the client device from which the traffic is received; identifying a plurality of second geographic locations corresponding to the plurality of sinkhole server identifiers; and wherein the one or more processors, when selecting the sinkhole server identifier, are configured to: The sinkhole server identifier associated with the sinkhole server that is geographically closest to the first geographic location is selected.

12. The network device of claim 8, wherein the one or more processors are further configured to: determining that a packet source network address satisfies matching criteria associated with the plurality of blacklisted domains; generating a message including the sinkhole server identifier; and sending the message to a device corresponding to the packet source network address, Wherein the message comprises a Domain Name System (DNS) response having a time-to-live value set to zero.

13. The network device of claim 8, wherein the one or more processors are further configured to: When the geographic proximity to the location of the client device cannot be determined, multiple sinkhole servers are load balanced via the round-robin scheduling process.

14. The network device of claim 8, wherein the one or more processors are further configured to: A geographic proximity algorithm is executed to select the sinkhole server that is closest to the location of the client device.

15. A non-transitory computer-readable medium storing an instruction set, the instruction set include: One or more instructions that, when executed by one or more processors, cause the one or more processors to: receiving a network address of a device hosting a plurality of blacklisted domains and a plurality of blacklisted domain identifiers corresponding to the plurality of blacklisted domains; Get a set of rules, wherein the set of rules specifies matching criteria associated with the plurality of blacklisted domains; receiving traffic destined for a destination device associated with a destination network address; determining, based on the matching criteria, that the destination network address corresponds to a network address among the network addresses; based on determining that the destination network address corresponds to the network address, determining that the network address corresponds to a blacklisted domain identifier of the plurality of blacklisted domain identifiers and that a threat level associated with the blacklisted domain identifier satisfies a threshold; selecting a sinkhole server identifier from a plurality of sinkhole server identifiers associated with the blacklisted domain identifier based on the threat level, The sinkhole server identifier is selected based on: geographic proximity to the location of the client device, or Round Robin Scheduling Process; and The traffic is redirected toward a sinkhole server associated with the sinkhole server identifier.

16. The non-transitory computer readable medium of claim 15, wherein the one or more instructions, when executed by the one or more processors, further cause the one or more processors to: Determining that the packet source network address satisfies the matching criteria; generating a message including the sinkhole server identifier; and sending the message to a device corresponding to the packet source network address, Wherein the message comprises a Domain Name System (DNS) response having a time-to-live value set to zero.

17. The non-transitory computer readable medium of claim 16, wherein the one or more instructions, when executed by the one or more processors, further cause the one or more processors to: monitoring a count of DNS requests received from a source network address prefix; and The DNS request is determined to be associated with an attacker based on the count satisfying a threshold.

18. The non-transitory computer readable medium of claim 15, wherein the one or more instructions, when executed by the one or more processors, further cause the one or more processors to: When the geographic proximity to the location of the client device cannot be determined, multiple sinkhole servers are load balanced via the round-robin scheduling process.

19. The non-transitory computer readable medium of claim 15, wherein the one or more instructions, when executed by the one or more processors, further cause the one or more processors to: A geographic proximity algorithm is executed to select the sinkhole server that is closest to the location of the client device.

20. The non-transitory computer readable medium of claim 15, wherein the one or more instructions, when executed by the one or more processors, further cause the one or more processors to: Intercept DNS messages exchanged between DNS resolver devices and DNS server devices, wherein the DNS message includes the network address of a device hosting the plurality of blacklisted domains; and The network address included in the DNS message is cached.

Images