AU2024200159B1 - Systems and methods for facilitating data transfer - Google Patents

Abstract

Described embodiments generally relate to a method for facilitating data transfer. The method comprises receiving a data packet from a client computing device via a data 5 connection; comparing an identifier of the data connection with entries in a state table to determine whether an active session exists for the connection; upon determining that no an active sessions exists for the connection, causing a selective acknowledgement to be sent to the client computing device, wherein the selective acknowledgement acts as a request for a previously sent data packet; and in response to receiving a compliant 10 response to the selective acknowledgement, recording the client computing device as a trusted client.

Description

"Systems and methods for facilitating data transfer"

Technical Field Described embodiments relate to systems and methods for facilitating data transfer between computing devices. In particular, described embodiments relate to systems and methods for facilitating data transfer while mitigating communication disruptions.

Background Cyber-attacks such as denial-of-service (DoS) attacks can severely disrupt the performance of server systems by preventing the transfer of data between the server system and legitimate third party devices. Defensive measures can be put in place in order to mitigate the risk of these types of attacks. For example, state tables can be used by network devices to keep track of trusted clients and accept traffic only from validated connections listed in the state table.

However, these types of defences can have negative effects on legitimate data transfer processes. For example, where a global network is involved, coordinating state tables across devices on the network is not instantaneous, and can therefore result in errors due to the latency in updating entries across the network devices. This can result in legitimate traffic being denied, or some illegitimate traffic being accepted, posing security risks.

It is desired to address or ameliorate one or more shortcomings or disadvantages associated with prior systems and methods for facilitating data transfer, or to at least provide a useful alternative thereto.

Throughout this specification the word "comprise", or variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps.

Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present disclosure as it existed before the priority date of each of the appended claims.

Summary

Some embodiments relate to a method for facilitating data transfer, the method comprising: receiving a data packet from a client computing device via a data connection; comparing an identifier of the data connection with entries in a state table to determine whether an active session exists for the connection; upon determining that no active session exists for the connection, causing a selective acknowledgement to be sent to the client computing device, wherein the selective acknowledgement acts as a request for a previously sent data packet; and in response to receiving a compliant response to the selective acknowledgement, recording the client computing device as a trusted client.

In some embodiments, recording the client computing device as a trusted client comprises adding an entry to the state table corresponding to the connection.

According to some embodiments, the selective acknowledgement comprises an acknowledgment to at least one data packet having a sequence number earlier than the received data packet.

According to some embodiments, the selective acknowledgement comprises an acknowledgment to a selection of data packets in a sequence of data packets being sent by the client computing device.

In some embodiments, the selective acknowledgement comprises an acknowledgment to all but one data packet in a sequence of data packets being sent by the client computing device.

In some embodiments, a compliant response is a response with a sequence number that matches a sequence number requested by the selective acknowledgement.

Some embodiments further comprise: receiving a response to the selective acknowledgement, comparing the sequence number of the response to a sequence number requested in the selective acknowledgement, and upon determining that the sequence number of the response matches the sequence number requested in the selective acknowledgement, determining that the response is a compliant response.

According to some embodiments, the entry corresponding to the connection is added to the state table without any handshake procedure having been performed with the client device to establish the connection.

In some embodiments, the entry corresponding to the connection is added to the state table without resetting the connection.

Some embodiments further comprise receiving a second packet from a second client computing device via a second data connection; comparing an identifier of the second data connection with entries in a state table to determine whether an active session exists for the second connection; upon determining that no active session exists for the second connection, causing a selective acknowledgement to be sent to the second client computing device, wherein the selective acknowledgement acts as a request for a previously sent data packet comprises an acknowledgment to a data packet having a sequence number earlier than the second data packet; and in response to not receiving a compliant response to the selective acknowledgement within a predetermined time period, dropping the second packet.

In some embodiments, not receiving a compliant response to the selective acknowledgement within a predetermined time period comprises receiving a non compliant response to the selective acknowledgement.

In some embodiments, a non -compliant response is a response with a sequence number that does not match a sequence number requested by the selective acknowledgement.

According to some embodiments, the predetermined time period is between 2 and 10 seconds.

In some embodiments, the predetermined time period is between 4 and 5 seconds.

In some embodiments, the predetermined time period is around 5 seconds.

Some embodiments further comprise, in response to not receiving a compliant response to the selective acknowledgement within a predetermined time period, recording the second client computing device as an untrusted client.

Some embodiments relate to a method for facilitating data transfer, the method comprising: receiving a data packet from a client computing device via a data connection; based on determining that a challenge mechanism is in place, performing the method of some other embodiments.

In some embodiments, the challenge mechanism is put in place in response to an anomaly being detected in previously received traffic.

Some embodiments relate to a computer readable medium storing program code which, when executed by a processor, causes the processor to perform the method of some other embodiments.

Some embodiments relate to a mitigation device comprising the computer readable medium of some other embodiments.

Some embodiments relate to a system for facilitating data transfer, the system comprising the mitigation device of some other embodiments and at least one server device.

Brief Description of Drawings Various ones of the appended drawings merely illustrate example embodiments of the present disclosure and cannot be considered as limiting its scope.

Figure 1 shows a diagrammatic representation of an example system for facilitating data transfer that blocks traffic from unknown devices according to previously known methods;

Figure 2 shows a diagrammatic representation of an example distributed system for facilitating data transfer according to previously known methods; Figure 3 shows a diagrammatic representation of a system for facilitating data transfer showing a re-routing process according to previously known methods; Figure 4 shows a diagrammatic representation of an example system for facilitating data transfer using a selective acknowledgement method; Figure 5 shows a diagrammatic representation of an example system and method for facilitating data transfer according to some embodiments; Figure 6 shows a block diagram of a system for facilitating data transfer according to some embodiments; Figure 7 shows a block diagram of the mitigation device of Figure 6 in further detail; and Figure 8 shows a flowchart illustrating an example method for facilitating data transfer that may be performed by the system of Figures 5, 6 and 7 according to some embodiments.

Description of Embodiments Described embodiments relate to systems and methods for facilitating data transfer between computing devices. In particular, described embodiments relate to systems and methods for facilitating data transfer while mitigating communication disruptions.

Data can be communicated between remotely situated computing devices via networks such as the internet. Once common communication protocol used to facilitate data transfer on the internet is the Transmission Control Protocol (TCP), which is a connection-oriented protocol. TCP can be used to serve web traffic between client and server devices via the internet.

Figure 1 shows an example system 100 illustrating how TCP can be used to set up connections and transmit data between devices or networks. In the illustrated embodiment, system 100 includes a client computing device 110, a server system 120 and a malicious computing device 140. Server system 120 comprises a server device 125. Client computing device 110 and malicious computing device 140 are both in communication with server device 125 via network 130 using TCP.

A TCP connection can be established between devices in system 100 using a three-step connection setup process where the client and server devices exchange control packets. The illustrated embodiment shows the three step process being performed by client computing device 110 and server device 125.

At a first step, client computing device 110 sends a synchronisation packet SYN 142 to server device 125. The state of client computing device 110 is changed to "SYN-SENT" indicating that a synchronisation packet has been sent. Upon receipt of synchronisation packet SYN 142, the state of server device 125 is changed to "SYN-RECEIVED" indicating that a synchronisation packet has been received.

At a second step, in response to receipt of the synchronisation packet SYN 142 from client computing device 110, server device 125 sends a synchronisation and acknowledgement packet SYN-ACK 144 to client computing device 110.

At a third step, in response to receipt of the synchronisation and acknowledgement packet SYN-ACK 144 from server device 125, client computing device 110 sends an acknowledgement packet ACK 146 to server device 125. The state of client computing device 110 is changed to "ESTABLISHED" indicating that the packet exchange or "handshake" was successful and that communication has been established with server device 125. Upon receipt of acknowledgement packet ACK 146, the state of server device 125 is also changed to "ESTABLISHED". Server device 125 may store the details of client computing device 110 in a state table to indicate that client computing device 110 is safe to communicate with. The state table may be used to maintain a list of trusted fingerprinted clients.

According to some embodiments, the state table may store information relating to a number of fields, which may be derived from the metadata associated with each established TCP connection with a trusted client. These fields may include at least one of the source IP address of the client, the destination IP address of the server, the source port of the client, the destination port of the server, and a timestamp associated with when the connection was established. These fields may be referred to as a flow, and the entries may be stored to the state table as a flow entry. According to some embodiments, entries to the state table may be in the form of a flow hash. For example, entries may be in the form of a three-tuple or a five-tuple hash, which may include at least one of the source

IP address, source port, destination IP address, destination port, and/or communication protocol being used in the communication.

According to some embodiments, entries to the state table may expire over time, or may be removed after a connection is closed. In some embodiments, connections may automatically expire after a predetermined duration has passed since the connection was established. The timestamp associated with each entry in the state table may be used to determine when an entry should expire and be removed. For example, in some embodiments, entries may expire 86400 seconds (or 24 hours) after the connection was established. Where an entry has a timestamp of N, the entry may therefore expire and be removed at N + 86400 seconds.

In some embodiments, entries may be removed from the state table in response to connections being closed. This may be down by way of a teardown procedure being performed by the client and server devices. At a first step, a first device wishing to close the connection may send a "FIN" packet indicating that is wants to terminate the connection. The state of the first device turns to a "FIN-WAIT" state in which it is waiting to an acknowledgement of the "FIN" packet. Upon receipt of the "FIN" packet, the second device may send back a "FIN-ACK" packet, acknowledging the received "FIN" packet and asking for acknowledgement from the first device. The state of the second device turns to a "FIN-WAIT" state in which it is waiting to an acknowledgement of its "FIN-ACK" packet. Finally, the first device sends an "ACK" acknowledging the "FIN-ACK" packet received from the second device. The state of the first device then turns to "CLOSED" indicating the connection has ended. Upon receipt of the "ACK" packet, the state of the second device also changes to "CLOSED". With the teardown complete, the state table stored by the server device can be updated to remove the entry related to that connection.

While an active entry relating to a connection with a client computing device 110 exists in the state table, server device 125 may readily accept traffic received from client computing device 110, allowing client computing device 110 to send data and otherwise communicate with server device 125. Server device 125 may consider client computing device 110 to be a validated, established, whitelisted and/or trusted connection. Packets received from devices that are not found in the state table may be dropped. This provides protection against disruptions that may be caused by some cyber-attacks, such as denial of-service (DoS) and distributed denial-of-service (DDoS) attacks.

System 100 includes an example of a malicious computing device 140 to illustrate this. Malicious computing device 140 sends acknowledgement packets 148A, 148B and 148C to server device 125. Malicious computing device 140 may do this in order to overwhelm server device 125, so that server device 125 does not have the resources to respond to legitimate traffic. However, as malicious computing device 140 has not performed the three-step handshake described above with respect to packets 142, 144 and 146, the traffic received from malicious computing device 140 is considered to be "out of state" and is dropped without being processed. To become whitelisted and have its traffic accepted, malicious computing device 140 would need to perform the three way handshake described above.

The system and method described above with reference to Figure 1 helps in mitigating DoS and DDoS attacks. However, problems can arise with this system and method where a global network is involved.

Figure 2 shows an example system 200 illustrating that use of state tables can result in faults where a global network of server devices exists. System 200 comprises a number of server devices or appliances making up a server system 205. These include a New York based server device NYC appliance 210, a Los Angeles based server device LAX appliance 220, a French based server device FRA appliance 230, a Singaporean based server device SIN appliance 240, a Hong Kong based server device HKG appliance 250, and a Sydney based server device SYD appliance 260.

As the appliances all belong to a global network, being server system 205, they may attempt to synchronise states by reading from each other's state tables and writing to their local state tables. For example, SYD database 265 may be a database storing a state table for SYD appliance 260. FRA appliance 230 may read from SYD database 265 and store the read entries to its local FRA database 235. Likewise, NYC appliance 210 may read from SYD database 265 and store the read entries to its local NYC database 215.

However, problems with synchronisation of state can occur across a global network with multiple locations as in the network shown in Figure 2. Stale entries can occur in databases where state changes are not recorded quickly enough, and the databases cannot be kept up to date in real time. This occurs due to the inherent database access latency caused by the round trip time of sending packets between the network device and the database. Similarly, retrieval of that data is also subject to a database access latency.

This can be illustrated using system 200. In system 200, SYD database 265 may be configured to act as a centralised database. In the illustrated embodiment, LAX appliance 220 establishes a connection with a client device 270 external to server system 205. Client device 270 has the IP address 192.168.0.1. This is written to SYD database 265 at a latency penalty of 160ms. This is received at SYD appliance 260 with a latency of Oms, since SYD database 265 is local to SYD appliance 260. It is also read by SIN appliance 240 at a latency of 91ms, HKG appliance 120ms, by FRA appliance 230 at a latency of 240ms and by NYC appliance 210 at a latency of 220ms.

However, client device 270 goes on to open and close a number of TCP sessions in rapid succession, with each exchange happening in less than 1OOms. In other words, the arrival time of the sessions is coming at a faster rate than the propagation time for the state table stored by SYD database 265. As client device 270 is completing their sessions so rapidly, LAX appliance 220 is still busy writing entries to SYD database 265 that no longer exist. This causes SYD database 265 to fill with stale entries. Other device, such as NYC appliance 210 and FRA appliance 230, read SYD database 265 and fill their tables within NYC database 215 and FRA database 235 with these stale entries corresponding to non existent sessions. This causes non-deterministic behaviour globally, as databases within server system 205 become out of sync with one another. This may also pose a security risk, as sessions that have been closed by client device 270 and should have been invalidated are still whitelisted in SYD database 265.

One solution to this problem is to avoid keeping a centralised database or state table. Instead, each network device within a global network can be configured to maintain its own local state table. In other words, the different devices in the network may be configured to not share or coordinate state at all. However, this can result in communication difficulties where certain devices or communication channels within a network are disrupted, as illustrated in Figure 3.

Figure 3 shows an example system 300 illustrating that use of distributed state tables can result in communication breakdown where a fault occurs in the communication network. System 300 comprises a number of server devices or appliances making up a server system 305. These include a London based server device LON appliance 310 and an Amsterdam based server device AMS appliance 320.

LON appliance 310 may be in communication with client device 370, which has an IP address of 192.168.0.1. Once communication between LON appliance 310 and client device 370 has been established, LON appliance 310 adds a corresponding entry to LON database 315, making client device 370 a whitelisted device. In normal operating conditions, LON appliance 310 can therefore actively accept traffic from client device 370.

However, a fault occurs in the cable connecting client device 370 to LON appliance 310. Client device 370 is redirected to AMS appliance 320. AMS appliance 320 starts receiving packets from client device 370 mid-stream, without any handshake, including a TCP handshake, having been performed between client device 370 and AMS appliance 320. AMS appliance 320 checks AMS database 325 to see whether a connection has previously been established with client device 370. However, AMS appliance 320 does not have knowledge of the state recorded by LON appliance 310 in LON database 315. From the perspective of AMS appliance 320, client device 370 is therefore out of state, and the packets received are dropped. Eventually, the connection would simply timeout, and the client device 370 would need to reset the connection, which would take further time and resources.

Figure 4 shows an example system 400 illustrating how a selective acknowledgment procedure can be used to initiate a resending of packets between devices. As described in further detail below with reference to Figure 5 to 8, the selective acknowledgement procedure can be leveraged to implement a challenge mechanism that allows for data connections to be reestablished after being redirected within a network, while maintaining the network security provided by state tables as described above.

System 400 comprises a client computing device 410 in communication with a server device 420 over a network 430. In the illustrated embodiment, client computing device 410 sends a request packet 452 to server device 420, requesting specific data from server device 420. Server device 420 responds by initiating the sending of the requested data in a number of data packets. Specifically, server device 420 sends a first segment of data in first segment packet 442, a second segment of data in second segment packet 444, a third segment of data in third segment packet 446 and a fourth segment of data in fourth segment packet 448. Each packet in the session is labelled with a sequence number. However, there is a fault, error or disruption when sending second segment packet 444, and second segment 444 never reaches computing device 410.

Client computing device 410 receives first segment 442 and responds by sending first acknowledgement packet 454. Client computing device 410 fails to receive second segment packet 444. The next packet that client computing device 410 receives is third segment packet 446. As the packets are sequentially numbered with sequence numbers, at this stage client computing device 410 determines that an error has occurred as they have not received second segment packet 444. Instead of sending an acknowledgement of third segment packet 446, client computing device 410 instead again acknowledges the first segment packet 442 by sending first acknowledgment packet 456. The next packet that client computing device 410 receives is fourth segment packet 448. Client computing device 410 determines that they have still not received second segment packet 444. Instead of sending an acknowledgement of fourth segment packet 448, client computing device 410 again acknowledges the first segment packet 442 by sending first acknowledgment packet 458.

Upon receipt of the multiple acknowledgements of first segment packet 442, being first acknowledgment packets 454, 456 and 458, server device 420 determines that client computing device 410 has not received second segment packet 444. Server device 420 therefore responds by resending the second segment in second segment packet 462, followed by third segment packet 464 and fourth segment packet 466. By selectively acknowledging the data packets that had been received, client computing device 410 was able to cause server device 420 to resend previously sent data.

Such a selective acknowledgement is used to acknowledge only certain packets of received data, to let a packet-sending device know when a particular packet has not been received. Specifically, selective acknowledgements are a feature of some TCP stacks that allow for one device to tell a device it is communicating with that it has received data up to a specific sequence number. As each packet in a communication session will have a sequence number, it is possible to acknowledge only certain packets in the sequence, allowing the other party to the communication to determine whether certain packets may not have been received. The party can then respond by resending any packets that have not been acknowledged.

In some alternative embodiments, a selective acknowledgment may acknowledge all of the packets that have been received by a device in a single packet. In the example described above with reference to Figure 4, client computing device 410 may alternatively have been configured to send a selective acknowledgement packet that referred to one or more packet segments that have been received in the sequence. For example, client computing device 410 may have sent a selective acknowledgement packet acknowledging the first segment packet 442, the third segment packet 446 and the fourth segment packet 448. In that case, on receipt of the selective acknowledgement and by comparing the packets that have been acknowledged with the packets that have been sent, server device 420 could determine that client computing device 410 has not received second segment packet 444.

The selective acknowledgement mechanism allows devices to submit multiple data packets in a series without explicitly waiting for an acknowledgement for each packet. This enables higher throughput, as having to acknowledge each packet in a zig-zag pattern at higher latencies introduces serious delays to the communication process. However, data transmission remains reliable as missed packets can be identified and retransmitted.

This selective acknowledgement technique can be leveraged to act as a challenge to a data sender. A TCP protocol-compliant device will respond to such a challenge, but a malicious device would not unless they were also running a compliant TCP stack. Many devices that initiate cyber-attacks would not be TCP compliant, and would act as stateless devices. Specifically, DDoS attacks are often stateless. Such devices would either send packets with a static sequence number, or use randomly generated sequence numbers, and so could not adequately respond to a challenge acknowledgement packet. As a result, implementing a challenge mechanism may mitigate the risk of such attacks.

Figure 5 shows an example system 500 illustrating how the selective acknowledgment procedure as described above with reference to Figure 4 can be leveraged to implement a challenge-response mechanism.

System 500 comprises a client computing device 510 in communication with a server device 520 over a network 530. Client computing device 510 and server device 520 have established a connection and are mid-stream in a data exchange. Specifically, server device 520 has sent a fourth segment packet 522 to client computing device 510, being the fourth of a series of data packets sent in response to a request received from client computing device.

However, after fourth segment packet 522 is sent, a fault 550 occurs in the connection between server device 520 and client computing device 510. Communication with client computing device 510 is redirected to server device 525 via network 530.

Client computing device 510 sends a fourth acknowledgement packet 524 in response to receipt of the fourth segment packet 522 from server device 520, acknowledging receipt of fourth segment packet 522. However, fourth acknowledgement packet 524 is redirected to server device 525, which has not yet communicated with client computing device 510. Packet 524 is the first in-session data packet that server device 525 has seen from client computing device 510, and so server device 525 does not have client computing device 510 listed in its state table. As server device 525 is not sure if client computing device 510 is a trusted computing device, server device sends client computing device 510 a challenge acknowledgement packet 526. The challenge acknowledgement packet 526 is in effect an acknowledgement of any one or more previous packets in the communication sequence. For example, challenge acknowledgement packet 526 may be an acknowledgement of the second packet sent by client computing device 510 in the sequence. From the point of view of client computing device 510, this appears to be signalling that the packets after the sequence number of the selectively acknowledged packet were not received. This acts as an instruction to client computing device 510 to resend the previous packets in the communication sequence. In the example where the challenge acknowledgement packet 526 is an acknowledgement of the second packet sent by client computing device 510, client computing device 510 may respond by resending the third and fourth packets in the sequence.

Client computing device 510 receives challenge acknowledge packet 526 and, as it is a compliant TCP stack, is caused to re-transmit the previously transmitted packets in the sequence, which were the third and fourth acknowledgement packets, being an acknowledgment of the third and fourth segment packets transmitted by server device 520. This is sent as retransmitted previous acknowledgement packet 528. Upon receipt of packet 528, server device 525 confirms whether the packets received from client computing device 510 are the packets requested, by comparing the sequence numbers of the received packets against the sequence numbers of the requested packets. If the sequence numbers match, server device 525 can add client computing device 510 to its local state table, as client computing device 510 is now considered a trusted device. While server device 520 would still have a local state table listing client computing device 510 as a trusted device, this entry would naturally expire when the timestamp associated with the entry expires.

In an alternative embodiment, challenge acknowledgement packet 526 may be an acknowledgement of multiple packets in the sequence, such as the first, second and fourth packet sent by client computing device 510. From the point of view of client computing device 510, this appears to be signalling that just the third packet in the sequence was not received. This acts as an instruction to client computing device 510 to resend the third packet. Client computing device 510 receives challenge acknowledge packet 526 and, as it is a compliant TCP stack, is caused to re-transmit the third acknowledgement packet. As above, server device 525 confirms whether the received packet was the requested packet, and adds the client computing device 510 to the state table if it confirms that the received packet was the packet with the requested sequence number.

Figure 5 demonstrates that in the event traffic is impeded by infrastructure failures or route flaps as described above with reference to Figure 3, the challenge-response mechanism as described above can be used to avoid needing to reset the connection with the client device or re-performing the three way handshake. This results in the connection being reestablished quickly and avoids having to resend many data packets, saving time and resources.

Figure 6 shows a system 600 configured to use the challenge-response mechanism as described above with reference to Figure 5 to facilitate data transfer. According to some embodiments, system 600 may be configured to provide more stable data connections than previously known methods. System 600 may be configured to mitigate cyber-attacks such as DDoS attacks that attempt to overwhelm network resources. System 600 may also avoid dropping legitimate data sessions, providing a more seamless experience to client devices even when system faults occur.

System 600 includes a plurality of client computing devices 610 in communication with a server system 640 over a network 630. While four client computing devices 610A, 610B, 610C and 610D are shown, any number of client computing devices 610 may be present. Some client computing devices 610 may be devices being used for legitimate purposes, while some client computing devices 610 may be being used for malicious purposes, such as to attack server system 640.

Each client computing device 610 may be a computing device such as a personal computer, laptop computer, desktop computer, tablet, or smart phone, for example. Each client computing device 610 may comprise a processor configured to read and execute program code, to cause the client computing device 610 to perform particular steps. These steps can include data retrieval, data processing and data storing steps, as well as data sending steps where data packets are sent to external computing devices such as those within server system 640. According to some embodiments, client computing devices 610 may be configured to communicate with server system 640 in order to access web based data. Client computing devices 610 may be configured to send requests for data to server system 640, and server system 640 may respond by providing the requested data via one or more data packets in the form of web traffic.

Server system 640 may comprise one or more server devices 650, which may comprise servers, databases, and/or processing devices in communication over a network and hosting one or more application programs, libraries, APIs or other software elements. In the illustrated embodiment, four server devices 650A, 650B, 650C and 650D are shown. However, server system 640 may comprise any number of server devices 650. The components of server system 640 may provide server-side functionality to one or more client applications. According to some embodiments, server system 640 may comprise a cloud based server system. While a single server system 640 is shown, server system 640 may comprise multiple systems of servers, databases, and/or processing devices.

In the illustrated embodiment, server system 640 further comprises a mitigation device 620. Mitigation device 620 may be configured to intercept network traffic and selectively transmit this traffic to server devices 650 in order to implement security measures.

Mitigation device 620 may comprise at least one processor 622 and a memory 624. Processor 622 may include one or more data processors for executing instructions, and may include one or more of a microprocessor, microcontroller-based platform, a suitable integrated circuit, and one or more application-specific integrated circuits (ASIC's). Memory 624 may include one or more memory storage locations, and may be in the form of ROM, RAM, flash or other memory types. Memory 624 is arranged to be accessible to processor 622, and to contain data that processor 622 is configured to read and write to.

Memory 624 further comprises program code that is executable by processor 622, to cause processor 622 to execute workflows. For example, memory 624 may store program code executable by processor 622 to cause server system 640 to perform server-side functions. According to some embodiments, server system 640 may comprise a web server such as Apache, IIS, NGINX, GWS, or an alternative web server. In some embodiments, memory 624 may store program code that is executable by processor 622, to cause processor 622 to execute method 800 as described in further detail below with reference to Figure 8.

Mitigation device 620 also comprises a communications module 626, to facilitate communication between mitigation device 620 and other devices. Communications module 626 may allow for wired or wireless communication between mitigation device 620 and other devices, and may utilise Wi-Fi, USB, Bluetooth, or other communications protocols. According to some embodiments, communications module 626 may facilitate communication between server devices 650 and client computing devices 610 via network 630, for example.

Server system 640 may include additional functional components to those illustrated and described, such as one or more firewalls (and/or other network security components), load balancers, and or other components.

The functions of mitigation device 620 implemented by processor 622 executing program code instructions stored in memory 624 are described in further detail below with reference to Figures 7 and 8.

Network 630 may comprise one or more local area networks or wide area networks that facilitate communication between elements of system 600. For example, according to some embodiments, network 630 may be the internet. However, network 630 may comprise at least a portion of any one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, some combination thereof, or so forth. Network 630 may include, for example, one or more of: a wireless network, a wired network, an internet, an intranet, a public network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a public-switched telephone network (PSTN), a cable network, a cellular network, a satellite network, a fibre-optic network, or some combination thereof.

According to some embodiments, mitigation device 620 may be configured to process all packets received from client computing devices 610 and perform a challenge acknowledgement process on any packets that have do not appear on a state table indicating whitelisted or trusted clients. In some alternative embodiments, mitigation device 620 may only start the challenge acknowledgement process where certain conditions are met. Specifically, mitigation device 620 may only start the challenge acknowledgement process where a deviation from ordinary traffic from client devices 610 is detected. This may be referred to as a selective challenge implementation.

Figure 7 illustrates some components of a mitigation device 620 that performs a challenge acknowledgment process in a selective challenge implementation. Mitigation device 620 may be configured to perform a challenge acknowledgment process in response to a detected change in received traffic. The components illustrated in Figure 7 may be implemented by processor 622 executing program code retrieved from memory 624, as described above.

Mitigation device 620 comprises a number of forwarding modules 710. While four forwarding modules 710A, 710B, 710C and 710D are illustrated, mitigation device 620 may include any number of forwarding modules. In some embodiments, the number of forwarding modules may depend on the number of CPU cores available on the mitigation device. For example, an Intel E-2288G may have 8 cores and 16 threads. By using hyperthreading to establish two threads per one core, a total of 16 threads would be available for forwarding packets, and so 16 forwarding modules could be established.

Forwarding modules 710 may be configured to receive incoming packets from client computing devices 610 directed to server system 640 as illustrated in Figure 6, and to send a selection of the received packets to heuristics engine 740 for analysis via queue 750. According to some embodiments, a random sampling of received packets may be forwarded by each forwarding module 710 to queue 750, to await processing by heuristics engine 740. In some embodiments, forwarding modules 710 may use a sampling rate of around 1:100 to sample incoming packets for sending to queue 750.

In some embodiments, forwarding modules 710 may comprise packet processing code and be configured to drop packets or to perform a challenge acknowledging process where packets are received via untrusted connections.

Heuristics engine 740 is configured to retrieve packets from queue 750 for analysis. Heuristics engine 740 may comprise a number of internal modules to identify abnormal patterns in traffic based on the received packets. Specifically, heuristics engine 740 may be configured to identify traffic patterns that may be indicative of a DDoS attack.

Heuristics engine 740 may comprise a packet feature matrix 742, a destination IP sampling 744, EWMA 746, SMA 748 and parameter comparison module 749.

The packet feature matrix 742 may be used to store a number of packet features for each received packet for analysis. Packet attributes stored in packet feature matrix 742 may include packet length, TCP flags, source ports, destination ports, source IP, destination IP, and any other features that may be desirable to analyse for abnormalities. Each packet feature stored in packet feature matrix 742 may be tracked against its bitrate and packet rate in real time.

As each packet feature is tracked against its bitrate and packet rate in real time, heuristics engine 742 may determine a moving average for the packet feature quantised into 50 microsecond blocks. According to some embodiments, heuristics engine 742 may determine an exponentially weighted moving average (EWMA) 746 and/or a simple moving average (SMA) 748 for each stored packet feature. The EWMA 746 may be used to detect sharp increases in anomalies, and may use an alpha value of 0.5. The SMA 748 may be used to establish a baseline for each packet feature, and may use a 2000 period lookback window to do so.

Heuristics engine 740 may further comprise a parameter comparison module 749. According to some embodiments, parameter comparison module 749 may be used to compare extracted or determined packet features against historic, previous or average packet feature values, or against predetermined threshold values. For example, in some embodiments parameter comparison module 749 may be used to compare the determined SMA 748 of a packet feature against the EWMA 746 of the packet feature, being an indication of the baseline of that feature. If the SMA 748 is greater than the EWMA 746 by a predetermined threshold, then heuristics engine 740 may determine that an anomaly has occurred, and that packets should be forwarded to selective acknowledgement module 730 to begin implementing the challenge-response mechanism.

Where no anomaly is detected, packets may simply pass through or bypass selective acknowledgement module 730 to be sent to agent pipes 720 and then passed to the appropriate server device 650 by forwarding modules 710.

Selective acknowledgment module 730 is configured to implement the challenge response mechanism by generating challenge acknowledgement packets to be sent to client computing devices 610 by forwarding agents 710, and to manage responses to the challenge acknowledgement packets received from the client computing devices 610.

Specifically, selective acknowledgment module 730 comprises state machine logic 732 which is configured to compare received packet parameters to a state table 734 to identify whether the packets have been received from a legitimate source, generate challenge acknowledgement packets to clients that are not yet trusted, record and track responses to send challenge acknowledgement packets, and record states of client connections into state table 734 based on their responses. The functions of the state machine logic 732 are described in further detail below with reference to method 800 of Figure 8. According to some embodiments, each step of method 800 may be a state that is tracked by state machine logic 732.

State table 734 is used to track states of connections with client computing devices 610. In some embodiments, state table 732 may comprise at least one of a blacklist table and a whitelist table. Trusted connections may be added to a whitelist table if a three-way handshake has been performed, or if a suitable response is received to a challenge acknowledgment packet within a predetermined timeframe, which may be around 5 seconds in some embodiments. In some embodiments the predetermined timeframe may be between 4 and 6 seconds. In some embodiments, the predetermined timeframe may be between 2 and 10 seconds. A suitable or compliant response may be any response where the sequence number of the packet matches the sequence number requested in the challenge acknowledgment packet.

Each entry to the whitelist table may be maintained until their TCP session with server system 640 terminates. Untrusted connections may be added to a blacklist table if no three-way handshake has been performed and no response to a challenge acknowledgement packet is received within the predetermined timeframe. Each entry to the blacklist table may be maintained for a predetermined fixed interval, which may be around 5 minutes in some embodiments.

Selective acknowledgement module 730 is configured to communicate instructions as determined by state machine logic 732 based on state table 734 to agent pipes 720. These instructions may include instructions to send challenge acknowledgement packets to client computing devices 610, instructions to drop packets, or instructions to transmit packets to the appropriate server device 650. Each agent pipe 720 may be a message queue that is used to communicate unidirectionally with the forwarding agents. Each agent pipe 720 is configured to pass these instructions to its corresponding forwarding agent 710.

The operation of mitigation device 620 is further explained below with reference to Figure 8.

Figure 8 is a process flow diagram of a method 800 of facilitating data transfer. In some embodiments, method 300 may be performed at least partially by processor 622 executing program code stored in memory 624 and/or by state machine logic 732. While certain steps of method 800 have been described as being executed by particular elements of system 600, such as by mitigation device 622, these steps may be performed by different elements in some embodiments.

At step 805, mitigation device 620 receives a data packet from a client computing device 610 over network 630. Specifically, a forwarding module 710 receives the data packet for processing.

At step 810, forwarding module 710 of mitigation device 620 determines whether the packet received at step 805 is a TCP packet. If the packet is not a TCP packet, method 800 continues to step 815 at which forwarding module 710 forwards the packet to an appropriate server device 650 for ordinary processing.

If forwarding module 710 determines that the received packet is a TCP packet, method 800 moves to optional step 812. Optional steps 812, 814 and 816 may be performed in embodiments with a selective challenge implementation, where the challenge acknowledgment process is only performed in response to identifying an anomaly in the received traffic. In embodiments whether challenge acknowledgement is always performed, steps 812, 814 and/or 816 may be omitted.

At optional step 812, forwarding module 710 of mitigation device 620 determines whether the packet is to be sampled, based on a predetermined sampling schedule.

If the packet is to be sampled, then at optional step 814 forwarding module 710 is caused to forward the packet to queue 750 to await processing by heuristics engine 814. Once processed, method 800 continues to step 816.

If the packet is not to be sampled, then the method proceeds straight to step 816 without performing step 814.

At optional step 816, mitigation device 620 determines whether packets are currently being challenged. In other words, mitigation device 620 determines whether or not the challenge-response mechanism is in place, and whether traffic is being challenged by selection acknowledgement module 730, based on the decision made by heuristics engine 740 in view of the sampled packets being analysed.

If no anomalies have been detected in traffic by heuristics engine 740 and no packets are being challenged, then method 800 proceeds to step 815 at which forwarding module 710 forwards the packet to an appropriate server device 650 for ordinary processing.

If packets are being challenged, such as due to an anomaly detected by heuristics engine 740, then method 800 proceeds to step 820.

At step 820, selective acknowledgement module 730 of mitigation device 620 checks state table 734 to determine whether the connection over which the packet was received is trusted. This may be by checking whether the connection has been previously whitelisted by being added to a whitelist stored in state table 734.

If the connection is trusted, then method 800 proceeds to step 815 at which forwarding module 710 forwards the packet to an appropriate server device 650 for ordinary processing.

If the connection is not trusted, then method 800 proceeds to step 825.

At step 825, selective acknowledgement module 730 of mitigation device 620 checks whether a challenge acknowledgement packet has been sent to the source of the packet.

If selective acknowledgement module 730 determines that no challenge acknowledgement packet has been sent, then method 800 proceeds to step 840. At step 840, selective acknowledgement module 730 generates a challenge acknowledgement packet and passes this to agent pipe 720 for sending to the client device by forwarding module 710. At step 845, selective acknowledgement module 730 then waits for a retransmit of data in response to the challenge acknowledgement. Method 800 then continues from step 830.

If a challenge acknowledgement had already been sent at step 825, method 800 moves straight to step 830.

At step 830, selective acknowledgement module 730 determined whether or not a suitable response to the challenge acknowledgement was received within a predetermined response timeframe. This may be around 5 seconds, for example. A suitable or compliant response may be any response where the sequence number of the packet matches the sequence number requested in the challenge acknowledgment packet.

If no suitable response is received within the predetermined timeframe, then method 800 proceeds to step 835, at which the packet is dropped. According to some embodiments, the client device from which the packet was received may be added to a blacklist or otherwise recorded or marked as an untrusted client or untrusted connection.

If a suitable response was received within the predetermined timeframe, then method 800 instead proceeds to step 850. At step 850, the connection is added to state table 734 as a trusted connection, whitelisted or otherwise marked or recorded as trusted or verified. In some embodiments, the client device from which the packet was received is added to state table 734 as a trusted client, whitelisted or otherwise marked or recorded as trusted or verified. Method 800 then proceeds to step 815, at forwarding module 710 forwards the packet to an appropriate server device 650 for ordinary processing.

Compared to some previously known techniques, described embodiments provide a method and system for reducing dropped connections during communication sessions, while also mitigating the risk of attack. The described systems and methods operate at line rate and in real time, which allows for an instantaneous response to malicious traffic while not impeding legitimate traffic flows. Trusted clients can be verified quickly without requiring a reset of the session of a repeat of the three-way handshake.

The described systems and methods may also reduce false positives compared to rate limiting or volume-based mitigation techniques. Furthermore, described systems and methods may reduce false negatives, as a fully stateful engine is used, compared to some other methods that may simply block all traffic containing similar characteristics to traffic that has been determined to be malicious. Furthermore, not all stateless traffic is rejected, meaning that connections can be quickly reestablished after network faults occur.

It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the above-described embodiments, without departing from the broad general scope of the present disclosure. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims (21)

CLAIMS:

1. A method for facilitating data transfer, the method comprising: receiving a data packet from a client computing device via a data connection; comparing an identifier of the data connection with entries in a state table to determine whether an active session exists for the connection; upon determining that no active session exists for the connection, causing a selective acknowledgement to be sent to the client computing device, wherein the selective acknowledgement acts as a request for a previously sent data packet; and in response to receiving a compliant response to the selective acknowledgement, recording the client computing device as a trusted client.

2. The method of claim 1, wherein recording the client computing device as a trusted client comprises adding an entry to the state table corresponding to the connection.

3. The method of claim 1 or claim 2, wherein the selective acknowledgement comprises an acknowledgment to at least one data packet having a sequence number earlier than the received data packet.

4. The method of any one of claims 1 to 3, wherein the selective acknowledgement comprises an acknowledgment to a selection of data packets in a sequence of data packets being sent by the client computing device.

5. The method of claim 4, wherein the selective acknowledgement comprises an acknowledgment to all but one data packet in a sequence of data packets being sent by the client computing device.

6. The method of any one of claims 1 to 5, wherein a compliant response is a response with a sequence number that matches a sequence number requested by the selective acknowledgement.

7. The method of any one of claims I to 6, further comprising: receiving a response to the selective acknowledgement, comparing the sequence number of the response to a sequence number requested in the selective acknowledgement, and upon determining that the sequence number of the response matches the sequence number requested in the selective acknowledgement, determining that the response is a compliant response.

8. The method of any one of claims 1 to 7, wherein the entry corresponding to the connection is added to the state table without any handshake procedure having been performed with the client device to establish the connection.

9. The method of any one of claims 1 to 8, wherein the entry corresponding to the connection is added to the state table without resetting the connection.

10. The method of any one of claims I to 9, further comprising: receiving a second packet from a second client computing device via a second data connection; comparing an identifier of the second data connection with entries in a state table to determine whether an active session exists for the second connection; upon determining that no active session exists for the second connection, causing a selective acknowledgement to be sent to the second client computing device, wherein the selective acknowledgement acts as a request for a previously sent data packet comprises an acknowledgment to a data packet having a sequence number earlier than the second data packet; and in response to not receiving a compliant response to the selective acknowledgement within a predetermined time period, dropping the second packet.

11. The method of claim 10, wherein not receiving a compliant response to the selective acknowledgement within a predetermined time period comprises receiving a non-compliant response to the selective acknowledgement.

12. The method of claim 11, wherein a non -compliant response is a response with a sequence number that does not match a sequence number requested by the selective acknowledgement.

13. The method of any one of claims 10 to 12, wherein the predetermined time period is between 2 and 10 seconds.

14. The method of claim 13, wherein the predetermined time period is between 4 and 5 seconds.

15. The method of claim 14, wherein the predetermined time period is around 5 seconds.

16. The method of any one of claims 10 to 15 further comprising, in response to not receiving a compliant response to the selective acknowledgement within a predetermined time period, recording the second client computing device as an untrusted client.

17. A method for facilitating data transfer, the method comprising: receiving a data packet from a client computing device via a data connection; based on determining that a challenge mechanism is in place, performing the method of any one of claims I to 16.

18. The method of claim 17, wherein the challenge mechanism is put in place in response to an anomaly being detected in previously received traffic.

19. A computer readable medium storing program code which, when executed by a processor, causes the processor to perform the method of any one of claims I to 18.

20. A mitigation device comprising the computer readable medium of claim 19.

21. A system for facilitating data transfer, the system comprising the mitigation device of claim 20 and at least one server device.