Increasing idle connection timeouts is unrelated to this type of attack - the time within which a TCP handshake must complete is a separate threshold governed by the Windows TCP/IP stack. An attacker attempts to create a large number of "half open" TCP connections by only partially completing the TCP handshake process. We will characterize the different types of DoS threats regarding incoming connections and show that increasing the idle connection timeout neither increases nor decreases the exposure to attack: However, using a heartbeat interval of 15-30 minutes has positive implications for battery life and bandwidth consumption: if the Direct Push sessions are permitted to live longer, there will be fewer HTTP roundtrips, less data sent and received, and less power consumed by the device. Now, the design of Direct Push makes no assumption as to the length of its sessions - email is delivered rapidly whether the heartbeat interval is one minute or thirty minutes. When either of those events occurs, the HTTP request is completed, but the connection is idle in the time between the request and response.
For Direct Push, the timeout of concern is the idle connection timeout that is, given a fully established TCP connection, for how long should that connection be permitted to live in the absence of traffic? Recall that the essence of Direct Push is a long-lived HTTP request: the device issues a request, and the server holds that request without responding until either a device-specified timeout (the "heartbeat interval") expires or new email arrives. Note, however, that there are timeout settings that can be safely increased without compromising the security of the network. IIS mitigates this threat by requiring that a client submit a fully-formed HTTP request within a certain time before dropping the connection. Similarly, a DoS attack could be mounted against IIS by opening a larger number of TCP connections but never actually issuing an HTTP request. For example, a denial-of-service (DoS) attack could be mounted by failing to complete the handshake that is implicit in the creation of a TCP connection, but the TCP stack in Windows mitigates this threat by requiring that the handshake complete within a finite time. Web servers, network security appliances, and system network stacks have a number of time-based thresholds that are intended to insulate these systems from buggy or malicious clients.
0 kommentar(er)
