SYN cookies

from Wikipedia, the free encyclopedia

Under SYN cookies is meant one of the 1996 Daniel J. Bernstein developed mechanism to protect against SYN flood attacks . These are a form of denial-of-service attack in which the computer to be attacked is provoked by massively opening connections to use its own resources to keep the connections open.

Connection establishment with TCP

When establishing a conventional TCP connection, the so-called three-way handshake , a client first sends a SYN packet to the server. This saves this message and replies with a SYN / ACK packet. Finally the client sends an ACK packet to the server and the connection is established.

Extension to include SYN cookies

The Transmission Control Protocol (TCP) does not specify the initial value of the sequence number of the SYN / ACK packets. So the server can use it to encode information that it would otherwise have to store in a table of half-open TCP connections. Since the table of half-open connections is not used with active SYN cookies, this table cannot be blocked, which means that a SYN flood attack is weakened.

The following rules can be applied in detail:

  • t is a slowly increasing timestamp that is recommended to be incremented every 64 seconds
  • m is the maximum packet size of the client
  • s is a hash value made up of the following values: the time stamp t , IP addresses and port numbers of the client and server . The hash value must be 24 bits long.

The server sends its SYN / ACK packet with a specially generated sequence number. However, according to the TCP specification, this sequence number is limited to 32 bits and can be generated as follows:

  • The first 5 bits: t mod 32
  • Middle 3 bits: An individual coding of m (only eight different possibilities)
  • The last 24 bits: s

Since the client counts up the sequence number of the TCP-SYN / ACK by one upon receipt, its TCP-ACK packet contains the initial sequence number generated by the server, incremented by one . The server decrements this again by one and then compares it with the hash value of the packet. If the two hashes do not match, the connection has to be re-established, for which the server sends the client a TCP RST packet.

In detail, the following happens on the server after the packet has been decremented:

  1. The first 5 bits must match the current calculation of t (or a timestamp before). Thus it can be found out whether a timeout has already occurred.
  2. The value s is calculated again from the time stamp t (or a previous time stamp), IP addresses and port numbers of the client and server and compared with the last 24 bits. The connection is only permitted if they match.
  3. The middle 3 bits are decoded and the connection is established with the desired maximum packet size.

Because the connection setup is checked on the server, the implementation hash function can in principle be freely defined; however, it should be as random as possible to avoid security risks. This procedure runs transparently for the client, which is why connections between remote stations can be established regardless of whether they use SYN cookies.

Content of the initial sequence number

  • Timestamp with a resolution of 64 seconds
  • maximum segment size
  • Hash function over:
    • Sender and recipient IP address
    • Ports
    • Timestamp with a resolution of 64 seconds
    • A secret value known only to the server, which changes (if at all) at large intervals

The hash function is not specified in the associated RFC 4987 and can therefore be freely selected.

Advantages and disadvantages of using SYN cookies

SYN cookies can mitigate denial-of-service attacks or prevent them in the case of smaller attacks. How well you protect against an attack depends on its type and extent. Because while the use of SYN cookies effectively prevents the table of half-open TCP connections from overflowing, their use costs more computing power due to the calculations required for this purpose than if no SYN cookies are used, which could possibly overload the server. In such a case the SYN flood attack would have failed, but the DOS attack itself would still be successful because the server literally “ran out of breath”. In addition, when using SYN cookies, it is not possible to use certain TCP extensions, such as large windows , because there is not enough space in the SYN cookie for the information required for this.

For these reasons, SYN cookies are often only used in practice, as is standard in the Linux kernel , for example , when the table of half-open TCP connections threatens to overflow. Although the clients that are served via SYN cookie cannot use certain TCP extensions, this is still better than if the server had to completely reject their connection request due to a lack of space. As soon as there is enough space in the table again, the SYN cookies are deactivated on the server side. In this way, the server can take advantage of the SYN cookies in the event of active attacks without having to accept their disadvantages in normal operation.

Web links

Individual evidence

  1. ^ S. Bellovin:  RFC 1948  - Defending Against Sequence Number Attacks . May 1996. p. 5. (AT&T Research).
  2. ↑ SYN cookies . Website of the SYN Cookies developer. Retrieved December 18, 2009.
  3. ↑ RFC 4987 - TCP SYN Flooding. Documentation of SYN cookies, p. 14 August 2007.
  4. ^ A b William Stallings, Lawrie Brown: Computer Security - Principles and Practice. 2nd Edition. Chapter 7: Denial of Service Attacks. Pearson Verlag, ISBN 0-273-76449-7 , pp. 263-264.