GB2588126A

GB2588126A - DNS Response Spoofing

Info

Publication number: GB2588126A
Application number: GB1914511.9A
Authority: GB
Inventors: Andrew John Oaten Lewis; James Cowan Alexander; Score Russell; Smith Daniel; D'arcy Harrison Rowan
Original assignee: Razorsecure Ltd
Current assignee: Razorsecure Ltd
Priority date: 2019-10-08
Filing date: 2019-10-08
Publication date: 2021-04-21
Anticipated expiration: 2039-10-08
Also published as: GB201914511D0; GB2588126B

Abstract

A method of analysing traffic between a first network device 10 and a second device, which may be a DNS server having a recursive resolver 11, comprises: receiving 906 at a third device, which may be a packet sniffer 16, a query data packet such as a DNS query from the first device; analysing 910 the contents thereof; and transmitting 914 to the first device dependent on the analysis a response data packet with a header having an identifier such as an IP address related to the second device. This may be a spoofed response which appears to have originated from resolver 11. Prior to analysis, the packet may be forwarded 908 to resolver 11. Analysing the query data packet may involve analysing a DNS request within the packet, and it may be determined whether the first device is permitted access to an address related to the request. For example, the service provided by the website server may be categorised by flagging requested names which are obscene, related to gambling or alcohol, or unacceptable to the government. The query data packet may include a transaction ID in its header to enable matching a returned response to a previously transmitted query.

Description

DNS Response Spoofing

Field of the disclosure

The present disclosure relates to a method of spoofing responses to domain name system (DNS) queries. In particular, but not exclusively, the present disclosure relates to transmitting a spoofed response to a user device based upon a DNS query transmitted by the user device.

Background

Within networks, domain names (e.g. www.exampleinvalid) are commonly used as a method of addressing servers, or groups of servers, to facilitate the communication of data. A domain name is entered into a web browser and subsequently this domain name is transferred to a DNS server in the form of a DNS query. This DNS server returns an Internet Protocol (IP) address that corresponds to the domain name and thereafter the browser communicates with this returned IP address. This process normally takes place without any input from the user beyond entering the domain name, so that the user is able to access a server (corresponding to an IP address) using only a domain name.

The domain names being entered by a user are of interest to any party monitoring the web traffic of the user device, not least since these domain names are useable to identify prohibited or inappropriate websites that a user is attempting to access. As a result, parties such as internet service providers (ISPs) sometimes analyse outgoing data packets to identify the names contained within DNS requests, for example to implement content filters. Commonly, ISPs implement filters by providing their own DNS servers, which are configured to return only the IP addresses of allowed websites. Problematically, users may be opposed to this, and so may attempt to conceal their browsing habits or circumvent the monitoring, e.g. by using different DNS servers.

Summary of the disclosure

According to an aspect of the disclosure herein, there is described: a method of analysing traffic between a first networked device and a second networked device, the method comprising: receiving at a third networked device a query data packet from the first networked device; analysing the contents of the query data packet; and transmitting a response data packet to the first networked device dependent upon the analysis, wherein a header of the response data packet comprises an identifier relating to the second networked device. This method enables a response to be returned to the first networked device from the third networked device, where the response appears, from the view of the first networked device, to come from the second networked device. Therefore, the -2 -first networked device will not identify that the response data packet is from a third networked device.

Preferably, the query data packet comprises a DNS query.

Preferably, the identifier comprises address information related to the second networked device, preferably wherein the address information comprises an IP address related to the second networked device.

Preferably, the query data packet is transmitted from the first networked device to the second networked device. Preferably, the third networked device intercepts the query data packet.

Preferably, the response data packet comprises a transaction ID contained within the query data packet Preferably, the identifier comprises an indication of the port from which the data packet was received. Preferably, a header of the response data packet comprises a destination port corresponding to a source port contained within the query data packet.

Preferably, transmitting a response data packet to the first networked device comprises transmitting the response data packet to the port from which the query data packet was received.

Preferably, the method further comprises transmitting the query data packet from the third networked device to the second networked device. Preferably, the query data packet is not altered before transmission to the second networked device.

Preferably, analysing the contents of the query data packet comprises analysing a DNS request within the data packet.

Preferably, analysing a DNS request comprises determining whether the first networked device is permitted to access a network address related to the DNS request. Preferably, the determination is dependent upon the information previously received from the first networked device.

Preferably, the response data packet comprises a time to live (TTL) value of less than 10 minutes. Preferably, less than 1 minute.

Preferably, the response data packet comprises an indication that the response data packet is not to be cached. Preferably, the indication is a time to live (TTL) value of 0.

Preferably, the response data packet comprises a time to live (TTL) value of greater than 1 hour. Preferably, greater than 12 hours.

Preferably, the second networked device is a DNS server. -3 -

Preferably, wherein transmitting a response data packet comprises returning an IP address that does not correspond to the contents of the DNS query.

Preferably, transmitting a response data packet comprises returning an IP address that corresponds to a website that is different to a website referenced in the query data packet.

Preferably, the response data packet comprises an error code.

Preferably, the method comprises transmitting a response data packet in less than 10ms Preferably, less than 5ms. Preferably, less than lms.

According to another aspect of the present disclosure, there is described: an apparatus for analysing traffic between a first networked device and a second networked device, the apparatus comprising: a receiver arranged to receive a query data packet from the first networked device, the query data packet comprising a DNS query; a processor arranged to analyse the contents of the query data packet; and a transmitter arranged to transmit a response data packet to the first networked device dependent upon the analysis wherein the header of the response data packet comprises an identifier relating to the second networked device.

Preferably, the receiver is arranged to monitor every data packet transmitted from the user device.

Preferably, both of the second networked device and the third networked device are arranged to receive query data packets from the first networked device. Preferably, both of the second networked device and the third networked device are arranged to receive query data packets from the first networked device substantially simultaneously.

Preferably, the third networked device is arranged to intercept query data packets sent from the first networked device to the second networked device. Preferably, the third networked device is arranged to forward the intercepted query data packets to the second networked device.

According to another aspect of the present disclosure, there is described: a computer program product comprising software code adapted when executed to carry out the aforesaid method.

According to another aspect of the present disclosure, there is described: an apparatus adapted to execute the aforesaid computer program product.

According to another aspect of the present disclosure, there is described: a router and/or modem comprising the aforesaid apparatus.

The disclosure extends to any novel aspects or features described and/or illustrated herein. -4 -

Further features of the disclosure are characterised by the other independent and dependent claims Any feature in one aspect of the disclosure may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus aspects, and vice versa.

Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.

Any apparatus feature as described herein may also be provided as a method feature, and vice versa. As used herein, means plus function features may be expressed alternatively in terms of their corresponding structure, such as a suitably programmed processor and associated memory.

It should also be appreciated that particular combinations of the various features described and defined in any aspects of the disclosure can be implemented and/or supplied and/or used independently.

The disclosure also provides a computer program and a computer program product comprising software code adapted, when executed on a data processing apparatus, to perform any of the methods described herein, including any or all of their component steps.

The disclosure also provides a computer program and a computer program product comprising software code which, when executed on a data processing apparatus, comprises any of the apparatus features described herein.

The disclosure also provides a computer program and a computer program product having an operating system which supports a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.

The disclosure also provides a computer readable medium having stored thereon the computer program as aforesaid.

The disclosure also provides a signal carrying the computer program as aforesaid, and a method of transmitting such a signal.

The disclosure extends to methods and/or apparatus substantially as herein described with reference to the accompanying drawings.

Preferred embodiments are described by way of example only, with references to the accompanying drawings. -5 -

Brief description of the drawings

Figure 1 is an illustration of a user device communicating with a website server using an IP address received from a recursive resolver via a packet sniffer; Figure 2 is an illustration of a generic computer device on which the packet sniffer is implemented; Figure 3 is an illustration of an exemplary data packet; Figures 4a and 4b are illustrations of the header section of the exemplary data packet of Figure 3; Figure 5 is an illustration of an exemplary DNS query; Figures 6a -6c are illustrations of a response section of the exemplary data packet of Figure 3; Figure 7 is a flowchart of a method of analysing and spoofing data packets containing DNS requests; Figure 8 is an illustration of the components of Figure 1 implementing the method of Figure 7; and Figure 9 is a flowchart of a further method of analysing and spoofing data packets. Detailed description Referring to Figure 1, a network 1 comprises a user device 10 in communication with a website server 15. The network 1 also comprises a recursive resolver 11, a root nameserver 12, a Top Level Domain (TLD) server 13, an authoritative nameserver 14, and a packet sniffer 16.

The user device 10 requires the Internet Protocol (IP) address of the website server 15 in order to communicate with the website server 15. In order to obtain this IF address, the user device 10 is arranged to communicate with the recursive resolver 11. More specifically, the user device 10 is arranged to transmit a data packet containing a Domain Name System (DNS) query to the recursive resolver 11, and the recursive resolver 11 is arranged to respond by transmitting a data packet containing the IP address to the user device 10.

The user device 10 may be any networked device, e.g. any device connected to other devices within the network 1. In this embodiment, the user device 10 is a laptop. In other embodiments the user device 10 is a smartphone, a games console, or a printer. The user device 10 may also comprise a router, which communicates with, for example, a -6 -laptop in an internal network (e.g. an intranet), and also communicates with, for example, a server in an external network (e.g. the internet).

In this embodiment, the network 1 is the internet and the communication is interacting with a website, which is hosted on the website server 15. In some embodiments, the network is a local area network (LAN) and the website server 15 is another device on the LAN, such as another user device. In general, the website server 15 may comprise any networked device connected to the network 1.

To obtain the IP address of the website server 15, the recursive resolver 11 is arranged to communicate with a root nameserver 12, a top level domain (TLD) server 13, and an authoritative nameserver 14. The combination of the recursive resolver 11, root nameserver 12, top level domain (TLD) server 13, and authoritative nameserver 14 comprises a DNS server, which is capable of responding to DNS queries received from the user device 10.

More specifically, the root nameserver 12 is arranged to communicate with the recursive resolver 11 to transmit an appropriate TLD server 13 with which the recursive resolver 11 communicates to obtain the IP address of the authoritative nameserver 14. The authoritative nameserver 14 is arranged to communicate with the recursive resolver 11 to transmit the IP address of the website server 15.

An aspect of the present disclosure relates to providing the packet sniffer 16, the packet sniffer 16 being a networked device arranged to intercept packets originating from the user device 10. In this embodiment, the packet sniffer 16 is arranged to communicate with the user device 10 and is arranged to communicate with the recursive resolver 11. More specifically, the packet sniffer 16 is arranged to receive each data packet transmitted from the user device 10 to the recursive resolver 11 and to analyse the received data packet. This may be considered to be intercepting the data packet. In this embodiment, the packet sniffer 16 is arranged to intercept all web traffic between the user device 10 and the recursive resolver 11. In some embodiments, the packet sniffer 16 is arranged to intercept all web traffic transmitted by the user device 10.

The packet sniffer 16 is arranged to 'sniff the data packets received from the user device 10. This involves the packets being received and, possibly immediately, forwarded to the recursive resolver 11. While in some embodiments, the packet sniffer 16 is capable of altering the contents of outgoing data packets, typically the packet sniffer 16 is arranged not to alter these contents. Since outgoing data packets are not altered, the packet sniffer 16 is able to go undetected by any of the devices on the network 1.

In some embodiments, the packet sniffer 16 does not intercept data packets sent from the user device 10, but instead analyses a copy of data packets sent from the user -7 -device 10, e.g. to the recursive resolver 11. In these embodiments, the device may be considered to not be "in-line" with the data traffic. Since there is no interception of data packets, the network infrastructure is not changed at all. In these embodiments, the packet sniffer 16 can be implemented without modifying the existing network infrastructure and so the packet sniffer 16 may easily be added to any existing network tap or router. Typically, in these embodiments identical data packets are separately and simultaneously, or near-simultaneously, transmitted from the user device 10 to both of the recursive resolver 11 and the packet sniffer 16.

The packet sniffer 16 is also arranged to spoof responses from other networked devices, e.g. to transmit responses so that they appear to have been transmitted from the other networked devices and/or to transmit responses in a way that obscures their origin. The packet sniffer 16 is in particular arranged to spoof responses from the recursive resolver 11. More specifically, the packet sniffer 16 is arranged to transmit a response to the user device 10 related to a data packet transmitted from the user device 10 to the recursive resolver 11. The packet sniffer 16 is arranged to format this response to comprise at least one identifier related to the data packet so that the spoofed response appears to the user device 10 to have been transmitted by the recursive resolver 11.

Referring to Figure 2, the packet sniffer 16, and each of the user device 10, the recursive resolver 11, the root nameserver 12, the TLD server 13, the authoritative nameserver 14, and the website server 15, is implemented on a computer device 200. In some embodiments, multiple component systems (e.g. the TLD server 13 and authoritative nameserver 14) are implemented on a single computer device 200, in other embodiments each component system is implemented on a separate computer device 200. The computer device 200 comprises a processor in the form of a CPU 202, a communication interface 204, a memory 206, storage 208 coupled to one another by a bus 214. A user interface 212 may also be included, comprising an input/output device, which in this embodiment is a keyboard 218 and a mouse 220. There may also be provided removable storage 210.

The CPU 202 executes instructions, including instructions stored in the memory 206, the storage 208, and/or the removable storage 210.

The communication interface 204 is typically an Ethernet network adaptor coupling the bus 214 to an Ethernet socket. The Ethernet socket is coupled to the network 1. In this embodiment, the network 1 is the internet. The Ethernet socket is usually coupled to the network 1 via a wired connection, but the connection could alternatively be wireless. The communication interface is typically arranged to receive and transmit information using the transmission control protocol (TCP) and the user datagram protocol (UDP), although other transmission protocols are useable. The communication interface comprises one or -8 -more ports 205 through which communications are received/transmitted. The use of a subset of the ports may be specified by a user or by convention. As an example, port '53' of the computer device 200 is typically reserved for receiving/transmitting DNS queries and responses to DNS queries.

The memory 206 stores instructions and other information for use by the CPU 202. The memory 206 is the main memory of the computer device 200. It usually comprises both Random Access Memory (RAM) and Read Only Memory (ROM).

The storage 208 provides mass storage for the computer device 200. In different implementations, the storage 208 is an integral storage device in the form of a hard disk device, a flash memory or some other similar solid state memory device, or an array of such devices.

The removable storage 210 provides auxiliary storage for the computer device 200. In different implementations, the removable storage 210 is a storage medium for a removable storage device, such as an optical disk, for example a Digital Versatile Disk (DVD), a portable flash drive or some other similar portable solid state memory device, or an array of such devices. In other embodiments, the removable storage 210 is remote from the computer device 200, and comprises a network storage device or a cloud-based storage device.

A computer program product is provided that includes instructions for carrying out aspects of the method(s) described below. The computer program product is stored, at different stages, in any one of the memory 206, storage device 208 and removable storage 210. The storage of the computer program product is non-transitory, except when instructions included in the computer program product are being executed by the CPU 202, in which case the instructions are sometimes stored temporarily in the CPU 202 or memory 206. It should also be noted that the removable storage 208 is removable from the computer device 200, such that the computer program product is held separately from the computer device 200 from time to time.

In some implementations, the computer device 200 on which the packet sniffer 16 is implemented comprises a router. The user interface 212 may then comprise a personal computer (PC) or laptop screen, which is connected to the router and via which aspects of the operation of the router may be observed and/or modified. The PC or laptop is useable to transfer information, such as software, to the communication interface 204 of the computer device 200, this information may comprise the computer program product as provided. -9 -

Referring to Figure 3, there is shown an exemplary data packet 300 that is transmitted from the user device 10 to the recursive resolver 11 and from the packet sniffer 16 to the user device 10.

The data packet 300 comprises: an IF' header 302, which contains information about the source, destination, and composition of the data packet 300; a UDP header 304, which contains information about the source and destination of the data packet as well as protocol specific details; and a payload 306, which contains information about a request.

Referring to Figure 4a, the IP header 302 is shown in further detail. The IP header 302 comprises at least a protocol 402, which indicates the protocol used by the data packet 300. Typically, the protocol 402 is either a transmission control protocol (TCP) or a user datagram protocol (UDP). In this example, a UDP protocol is used. The IP header 302 further comprises a source IP address 404 and a destination IP address 406.

For data packets 300 being transmitted from the user device 10, the source IP address 404 is that of the user device 10 and the destination IP address 406 is that of the recursive resolver 11. For data packets 300 being transmitted to the user device 10 from the packet sniffer 16, the source IP address 404 is that of the recursive resolver 11, as is described in more detail with reference to Figures 8, 9, and 10, and the destination IP address 406 is that of the user device 10.

Referring to Figure 4b, the UDP header 304 comprises at least a source port 408, which indicates the origin port of the data packet 300, and a destination port 410, which indicates the intended receipt port of the data packet 300. The UDP header 304 may also comprise protocol specific information.

The payload 306 of the data packet 300 typically comprises a DNS query as shown by Figure 5-in this example, the payload 306 is a DNS query.

The DNS query 306 comprises a header 402, a question section 504, an answer section 506, an authority section 508, and an additional section 510.

The header 502 comprises information about the content of the DNS query 500, and is further described with reference to Figure 6a. The question section 504 comprises one or more DNS requests that relate to one or more names. In this embodiment the name is a domain name, for example the question section 504 may contain a DNS request for the IP address related to the domain name www.example.invalid. The answer section 506 comprises information related to the DNS requests within the question section 504, such as an IP address relating to the name. The authority section 508 comprises records relating to the authoritative nameserver(s) 14 that has been used to resolve the DNS requests contained in the question section 504. The additional section 510 comprises any -10 -further information that may be of use in the resolution of the current query or expected subsequent queries -for example the IP addresses of other authoritative nameservers that may contain relevant records.

In operation, the user device 10 fills in the header 502 and the question section 504 of the DNS query 306 with information related to one or more DNS requests. The remaining sections 506, 508, 510 are left empty. The DNS query 306 is then transmitted to the recursive resolver 11, which copies the header 502 and question section 504, modifying information as appropriate, e.g. modifying the header indicate that the response is a response, and fills in the remaining sections 506, 508, 510 with relevant information, e.g. the answer section is filled in with the relevant IP addresses received from the authoritative nameserver 14.

Referring to Figure 6a, the header 502 of the exemplary DNS query 306 is shown in more detail.

The header 502 comprises a transaction ID 602, a flags and codes section 604, a question count 606, an answer count 608, a nameserver count 610, and an additional record count 612.

The transaction ID 602 comprises a binary identification code, e.g. a 16 bit, binary identification code, and is useable by the user device 10 to match a returned response to a previously transmitted DNS query. The flags and codes section 604 is further described with reference to Figure 4b. The question count section 606 comprises information about the number of queries in the question section 504 of the DNS query 306. The answer record count section 608 comprises information about the number of answers in the answer section 506 of the data packet. The nameserver count section 610 comprises information about the number of nameservers in the authority section 508 of the data packet. The additional record count section 612 comprises information about the quantity of additional information in the additional section 510 of the DNS query 306.

Referring to Figure 6b, the flags and codes section 604 of the header 502 of the exemplary DNS query 306 is shown.

The flags and codes section comprises a Query Response (QR) flag 622, an operation code 624, an authoritative answer flag 626, a truncation flag 628, a recursion desired flag 630, a recursion available flag 632, a zero section 634, and a response code 636. The illustration of Figure 6b does not show these sections to scale.

The QR flag 622 comprises an indication of whether the DNS query 306 relates to a query or a response. Typically, a value of 0 is used to denote a query and a value of 1 is used to denote a response.

The operation code 624 comprises an indication of the type of query contained within the DNS query 306. The operation code 624 is used by the recursive resolver 11 to return an appropriate response. Typical values are 0 for a standard query, 1 for an inverse query (a request to find a name from an IP address), and 2 for a server status request.

The authoritative answer flag 626 comprises an indication of whether the server creating the response is authoritative for the zone of the domain name specified in the question section 504, e.g. there may be an indication of whether the server from which the DNS query 306 is being transmitted contains relevant records for the.invalid domain.

The truncation flag 628 comprises an indication of whether the response has been truncated due to length limitations. This is particularly relevant for DNS queries 306 using the UDP protocol, which may be limited to a size of 65,535 bytes.

The recursion desired flag 630 comprises an indication of whether the recursive resolver 11 should attempt to respond to the DNS query recursively. The recursion available flag 632 comprises an indication of whether the recursive resolver 11 is capable of recursive queries. The zero section 634 comprises a section reserved for zero bits. The response code 636 comprises an indication of any errors in the response by type. As an example, a value of 0 may indicate no error has occurred.

The operation code 624, recursion desired flag 630, and zero section 634 are arranged to be set by the user device 10 and copied by the recursive resolve 11. The QR flag 622 is arranged to be set by the user device 10 and modified by the recursive resolver 11.

The authoritative answer flag 626, truncation flag 628, recursion available flag 632, and response code 636 are arranged to be set by the recursive resolver 11 (or another responding server).

Referring to Figure 6c, an exemplary resource section 640 is shown. Each of question section 504, the answer section 506, the authority section 508, and the additional section 510 are typically implemented as such a resource section. That is, the DNS query 306 comprises a number of such resource sections 640.

The resource section 640 comprises a name section 642, a type section 644, a class section 646, a time to live (TTL) 648, a resource data length 650, and resource data 652.

The name section 642 comprises the name related to the query (e.g. www.example.invalid). The type section 644 comprises a code related to the resource data 652 contained in the resource section 640. For example, the code may indicate that the resource data 652 comprises the IP address of a website, or that the resource data 652 comprises the IP address for the authoritative nameserver 14. The class section 646 comprises a code relating to the identity of the network 1, for example the code "IN" -12 -relates to a query for an internet IP address. The TTL 648 comprises an indication, e.g. in seconds, of the length of time for which the resource data 652 is valid. In the context of the answer section 506, this TTL relates to the amount of time for which the user device 10 continues to use the returned IP address in communications related to the queried name.

In order to reduce the time taken to resolve DNS requests, the user device 10 may cache returned requests within the memory 206 or the storage 208 of the user device 10. When a DNS request is formulated, the cache is checked for relevant information before a DNS query 306 is transmitted to the recursive resolver 11. If the cache contains an IP address corresponding to the DNS request, the DNS query 306 is not transmitted. Once the TTL 648 of the resource section 640 related to that IF address has been exceeded, the records derived from the related resource section 640 are removed from the cache of the user device 10. A TTL 648 of zero preferably denotes that the associated resource section 640 should not be cached.

The resource data length 640 comprises an indication of the length of the resource data 652.

The resource data 652 comprises data related to the DNS query. In the context of the answer section 506, the resource data 652 may comprise an IP address that relates to a name specified within the question section 504 of the DNS query 306.

In operation, the packet sniffer 16: receives the DNS query 306 from the user device 10; copies the header 502 and the question section 504 modifying the flags and codes 604, answer record count 608, name server count 610, additional record count 612 as appropriate; fills in the answer section 506, authority section 508, and additional section 510; and transmits the response to the user device 10.

Referring to Figure 7, the operation of the packet sniffer 16 is described in more detail.

In a first step 702, the packet sniffer 16 receives the data packet 300 from the user device 10 via the communication interface 204. The data packet 300 contains a DNS query 306, the DNS query 306 contains information related to a DNS request. The data packet 300 is received from a specific port of the communication interface 204, the source port 408 is identified within the UDP header 304. The data packet further contains information related to the intended destination IF address 406 and the intended destination port 410.

In a second step 704, the packet sniffer 16 identifies a DNS request within the DNS query 306.

-13 -In a third step 706, the DNS request contained in the DNS query 306 is analysed by the packet sniffer 16. More specifically, the website server 15, and/or the service provided by the website server 15, which the user device is attempting to access is categorised. This may involve, for example, identifying the name being requested by the user (obscene names, or those related to gambling/alcohol may be flagged) and/or identifying a group to which the name belongs (e.g. has it been flagged by the government or an ISP as being unacceptable, or is it from a domain known to be disallowed).

In a fifth step 708, it is determined whether the request is allowable. This comprises determining whether a user is authorised to access the website server 15 related to the DNS request and may comprise checking the name within the DNS request against a list of banned websites and/or using word recognition/classification to determine that the name relates to prohibited subject matter.

In some embodiments, this allowability check involves evaluation of previous user behaviours and/or transmission of the DNS query to another server.

If the query is allowable, the packet sniffer 16 takes no further action The data packet 300 is forwarded to the recursive resolver 11 and the response returned from the recursive resolver 11 is transmitted to the user device 10. In some embodiments, the data packet 300 and/or the response is retained and evaluated to determine user behaviours.

If the query is not allowable, in a sixth step 710, the packet sniffer 16 creates a spoofed query response. This response comprises an identifier related to the DNS query 306, e.g. the source IF address 404 of the data packet 300 transmitted to the user device 10 may comprise the IF address of the intended recipient (the recursive resolver 11) as is identifiable from the destination IF address 406 of the data packet 300 received from the user device 10; similarly, the source port 408 of the spoofed response may be set to be the destination port 410 of the data packet 300 received from the user device 10; and/or the transaction ID 402 of the spoofed response may be set to be that of the data packet 300 received from the user device 10. The spoofed response thus appears to the user device 10 to have originated at the recursive resolver 11 and to have been formulated in response to the transmitted DNS query.

Spoofing may comprise mimicking further details of the response that might be expected. For example, the authority section 508 of the DNS query 306 may be filled in with authoritative nameservers relevant to the DNS request, even if these authoritative nameservers are not used (as may occur if the request is not allowable). More specifically, authoritative nameservers may be specified which do not correspond to the IF addresses contained in the answer section 504.

-14 -In a seventh step 712, the packet sniffer 16 transmits the spoofed response to the user device 10. Since the spoofed response appears to be the intended response to the transmitted DNS query, this response will be accepted by the user device 10 as the response to the transmitted query.

Once the response is received by the querying port of the user device 10, the querying port stops listening for responses. Therefore, if an authentic response is later returned by the recursive resolver 11, it WV not be 'heard' or considered by the user device 10. As a result, there is no need to tamper with the outgoing data packet 300 and so the recursive resolver 11 or any other component may still receive the DNS query 306 and may not be aware that a spoofed message has been transmitted. While the recursive resolver 11 may receive an internet control message protocol (ICMP) 'destination unreachable' message, this is a commonly received error message and would not indicate to the recursive resolver 11 that a spoofed package had already been received by the user device 10.

Accordingly, and conversely to the situation that occurs when an ISP enforces use of its own DNS servers to resolve DNS queries, there is no clear evidence of how an outgoing DNS query has been analysed, nor even that it has been analysed, by any device other than the recursive resolver 11.

In an optional eighth step 714, the data packet is forwarded to the intended recipient, e.g. the user 10. Typically, The original data packet 300 is not altered. This forwarding may occur at any point during the process, so that it may occur immediately upon receipt of the data packet 300. This would reduce any latency reduction that occurs due to use of the packet sniffer 16 where the query is allowable.

In some embodiments, where the data packet 300 is forwarded immediately, a spoofed response is returned in less than 10ms, preferably less than 5ms, more preferably less than 1ms to ensure that this response arrives before the authentic response.

The method of Figure 7 method is further illustrated in Figure 8, which shows the flow of information between the user device 10, the packet sniffer 16, and the recursive resolver 11.

Also shown in Figure 8 is the transmission of a port unreachable message 806. The spoofed response 802 transmitted from the packet sniffer 16 to the user device 10 is received prior to the authentic response 804, resulting in the closure of the relevant port of the user device. When this port subsequently receives the authentic message, an unreachable message 806 is sent to the recursive resolver 11, and the authentic response 804 is not received by the user device 10.

-15 -The spoofed response 802 may comprise an invalid response, for example the response code 636 may be set to identify that the query is invalid. This results in no webpage being loaded. The spoof response may also comprise a redirect, where the user is sent to a different server, for example one set up by an ISP.

As previously explained, in order to reduce the time taken to resolve DNS requests, the user device 10 may cache returned requests within the memory 206 or the storage 208 of the user device 10. Spoofed requests stored in the cache can result in a user being unable to access a webpage even when that user changes their network connection, since a query is answered by querying the cache and not the (second) network -in these instances the DNS cache is said to be 'poisoned'. To prevent this problem -DNS cache poisoning' -from occurring, the TTL 648 of the response sent by the packet sniffer 16 is typically set to be small, e.g. less than an hour or less than a minute. In some embodiments, the TTL of each spoofed response is 0, so that the information contained in the response is not cached at all. This leads to a new DNS query being generated each time a connection attempt is made. In some embodiments, such poisoning is desirable, and the TTL value of the spoofed response is large, for example the TTL vale may be greater than 1 hour, or greater than 24 hours.

In some embodiments, previous user behaviour is used to determine the TTL 648 of the response, to determine whether a website is allowable, and/or to determine what happens if a website is not allowable. For example, there may be for each user a bespoke redirect that occurs when prohibited sites are requested. Previous user behaviour may be used to determine, for example, the age of a user, or the knowledge of a user, where allowable sites may be determined based upon this. Young users may be prevented from accessing certain types of websites, e.g. gambling websites.

Similarly, prohibited sites may be identified based upon user behaviour, for example by monitoring which sites are accessed within a certain time period of each other. In some embodiments, machine leaming algorithms are used for analysis of historic user behaviour.

Referring to Figure 9, there is shown a flowchart for a further implementation of the method.

In a first step 902, the user device 10 attempts to access the website server 15, for example via a web browser. This results in a data packet 300 being generated, the data packet 300 being intended for the recursive resolver 11.

In a second step 904, the user device 10 transmits the data packet 300 to the recursive resolver 11. The data packet 300 is also transmitted to the packet sniffer 16; equally, the data packet 300 may be intercepted by the packet sniffer 16.

-16 -In a third step 906, this data packet 300 is received by the packet sniffer 16, which is monitoring network traffic within the network 1. The user device 10 receives no indication that the data packet 300 has been intercepted.

In an optional fourth step, the data packet 300 is forwarded from the packet sniffer 16 to the recursive resolver 11.

In a fifth step 910, the packet sniffer analyses a DNS request within the data packet 300. More specifically, the packet sniffer analyses a DNS request within the question section 504 of a DNS query 306 contained within the payload section of the data packet 300.

In a sixth step 912, it is determined whether the request is allowable. If the request is allowable, no further action is taken.

If the request is not allowable, in a seventh step 914, a spoofed response is transmitted from the packet sniffer 16 to the user device 10. This response is arranged to appear to the user device 10 to come from the recursive resolver 11. In this embodiment, this occurs by altering a header within the data packet 300, for example the IP header 302 may be modified so that the source IP address 404 of the spoofed response data packet is that of the recursive resolver 11.

In an eighth step 916, that follows the optional fourth step 908, the recursive resolver 11 receives the forwarded data packet 300 from the packet sniffer 16.

In a ninth step 918, the recursive resolver 11 identifies an IP address corresponding to a DNS request within the data packet 300. This may involve the recursive resolver 11 communicating with the root nameserver 12, the TLD server 13, and/or the authoritative nameserver 14 In a tenth step 920, the recursive resolver 11 transmits a data packet to the user device 10 containing the IP address corresponding to the DNS request.

The fifth step 910 and the eighth step 916 may proceed simultaneously, however the packet sniffer 16 is arranged to transmit the spoofed response so that it arrives prior to the response from the recursive resolver 11. Therefore, where a spoofed response is the transmitted by the packet sniffer, the authentic response from the recursive resolver 11 is not processed by the user device 10.

Instead, if the recursive resolver 11 has transmitted an authentic response, in an eleventh step 922, an error message is transmitted to the recursive resolver 11 and in a twelfth step 924, the error message is received by the recursive resolver 11.

Where the DNS request contained within the data packet 300 is allowable, the packet sniffer does not transmit a spoofed response and so the response transmitted by the -17 -recursive resolver 11 is received and processed by the user device 10. In this case, no error message is transmitted to the recursive resolver 11.

Alternatives and modifications It will be understood that the present disclosure has been described above purely by way of example, and modifications of detail can be made within the scope of the invention.

The packet sniffer 16 may spoof the IP address of the user device 10 during communications with the recursive resolver 11, so that the recursive resolver 11 is not capable of detecting the presence of the packet sniffer 16. Where the packet sniffer is implemented on an intemal network, for example a router, the outgoing traffic may undergo network address translation (NAT), which may further obscure the presence of the packet sniffer 16.

While the detailed description has primarily considered the use of the packet sniffer 16 for blocking websites or redirecting the user device 10, the methods described herein have many additional uses. These methods could for example be used to identify malicious, or compromised, DNS servers or to record user's behaviour to determine usage patterns. In particular, a response received by the packet sniffer 16 from the recursive resolver 11 may be analysed to ensure that the response does not contain any undesirable information, e.g. the IP address of a server containing malware.

The detailed description relates to the packet sniffer 16 being arranged between the user device 10 and the recursive resolver 1 1. In some embodiments, the packet sniffer 16 may similarly be arranged between any other pair of components e.g. between the recursive resolver 11 and the root nameserver 12. In these embodiments, the packet sniffer 16 spoofs a response as described purporting to be the intended recipient of the DNS query 306. For example, where the packet sniffer 16 is arranged between the recursive resolver 11 and the root nameserver 12, the packet sniffer 16 spoofs a response to the recursive resolver 11 using the IP address of the root nameserver 12. This response is useable to redirect the recursive resolver 11 to a TLD server (and subsequently an authoritative nameserver) chosen by the operator of the packet sniffer 16.

Equally, the packet sniffer 16 may be located in parallel with another device and be arranged to observe a copy of the data packet 300 sent between any two devices without intercepting the data packet 300.

The methods disclosed herein would be equally valid where the website server 15 comprises the networked device of another user, where these may be referred to by name (e.g. 'Jack's computer' and 'Jill's computer). These names may be related to an IP address by a server, such as the recursive resolver 11, upon receipt of a data packet -18 -comprising the names. The packet sniffer 16 as described may be arranged to identify the related request within this data packet, e.g. by identifying a name within the data packet 300. Such an implementation may be used to, for example, prevent to users on a network from interacting, to prevent a user from interacting with a networked component (e.g. a smart TV), or to prevent specific types of interaction, e.g. sending images.

While the detailed description has considered the use of a recursive resolver 11, any other type of domain name server (DNS) may be used. For example, an iterative DNS may be used, where this may result in a system wherein only a single iterative DNS is queried.

In some embodiments, the packet sniffer 16 is implemented on a router and the user device 10 is implemented upon the same router. Here the user device may specify a port of the router from which to transmit the data packet. In some of these embodiments, the router generates a spoofed response purporting to be sent from, and returned via, this port without said sending or returning occurring.

In some embodiments, contents of the DNS query 306 that are not the DNS request are analysed. As an example, the time of the request may be analysed, where this is useable to prevent users from accessing sites during certain times. The sender of the data packet 300 may also be analysed, preferably in conjunction with the user query, to determine whether a site is allowable.

While the detailed description has considered whether sites are allowed in the context of users being authorised to access a site, the packet sniffer 16 may perform a variety of other actions after identify the website related to a DNS request. The packet sniffer 16 may identify website servers 15 related to a query received from the user device 10 and may make suggestions based upon this. For example, the packet sniffer 16 may detect that a user is viewing websites related to a specific topic and suggest further reading. In this case, an allowable' site may be a recommended site, where a prohibited' site is a less recommended site. A site that is not allowable' is not necessarily blocked, but may be result in a redirect being sent the first time a user to access it. The user device 10 may be allowed to obtain the IF address of the website server 15 only if multiple connection attempts are made.

Reference numerals appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.

Claims

-19 -Claims 1 A method of analysing traffic between a first networked device and a second networked device, the method comprising: receiving at a third networked device a query data packet from the first networked device; analysing the contents of the query data packet; and transmitting a response data packet to the first networked device dependent upon the analysis, wherein a header of the response data packet comprises an identifier relating to the second networked device.
2. The method according to claim 1, wherein the query data packet comprises a DNS query.
3 The method according to claim 1, wherein the identifier comprises address information related to the second networked device, preferably wherein the address information comprises an IP address related to the second networked device.
4 The method of any preceding claim, wherein the query data packet is transmitted from the first networked device to the second networked device, preferably wherein the third networked device intercepts the query data packet.
5. The method according to any one of the preceding claims, wherein the response data packet comprises a transaction ID contained within the query data packet
6 The method according to any one of the preceding claims, wherein the identifier comprises an indication of the port from which the data packet was received, preferably wherein a header of the response data packet comprises a destination port corresponding to a source port contained within the query data packet.
7 The method according to claim 6, wherein transmitting a response data packet to the first networked device comprises transmitting the response data packet to the port from which the query data packet was received.
8 The method according to any one of the preceding claims, further comprising transmitting the query data packet from the third networked device to the second networked device, preferably wherein the query data packet is not altered before transmission to the second networked device.-20 -
9 The method according to any one of the preceding claims wherein analysing the contents of the query data packet comprises analysing a DNS request within the data packet.
10. The method according to claim 9, wherein analysing a DNS request comprises determining whether the first networked device is permitted to access a network address related to the DNS request, preferably wherein the determination is dependent upon the information previously received from the first networked device.
11. The method according to any one of the preceding claims, wherein the response data packet comprises a time to live (TTL) value of less than 10 minutes, preferably of less than 1 minute.
12. The method according to any preceding claim, wherein the response data packet comprises an indication that the response data packet is not to be cached, preferably wherein the indication is a time to live (TTL) value of 0.
13. The method according to any one of claims 1 to 10, wherein the response data packet comprises a time to live (TTL) value of greater than 1 hour, preferably greater than 12 hours.
14. The method according to any one of the preceding claims, wherein the second networked device is a DNS server.
15. The method according to any one of the preceding claims, wherein transmitting a response data packet comprises returning an IF address that does not correspond to the contents of the DNS query.
16. The method according to any one of the preceding claims, wherein transmitting a response data packet comprises returning an IF address that corresponds to a website that is different to a website referenced in the query data packet.
17. The method according to any one of the preceding claims, wherein the response data packet comprises an error code.
18. The method according to any one of the preceding claims, comprising transmitting a response data packet in less than 10ms, more preferably less than 5ms, yet more preferably less than 1ms. -21 -
19. An apparatus for analysing traffic between a first networked device and a second networked device, the apparatus comprising: a receiver arranged to receive a query data packet from the first networked device, preferably wherein the query data packet comprises a DNS query; a processor arranged to analyse the contents of the query data packet; and a transmitter arranged to transmit a response data packet to the first networked device dependent upon the analysis wherein the header of the response data packet comprises an identifier relating to the second networked device.
20. The apparatus according to claim 19, wherein the receiver is arranged to monitor every data packet transmitted from the user device.
21. The apparatus according to claim 19 or 20, wherein both of the second networked device and the third networked device are arranged to receive query data packets from the first networked device, preferably substantially simultaneously.
22. The apparatus according to any of claims 19 to 21, wherein the third networked device is arranged to intercept query data packets sent from the first networked device to the second networked device, preferably wherein the third networked device is arranged to forward the intercepted query data packets to the second networked device.
23. A computer program product comprising software code adapted when executed to carry out the method of any of claims 1 to 18.
24. An apparatus adapted to execute the computer program product of claim 23.
25. A router and/or modem comprising the apparatus of claim 24.