Syn-proxy è un protocollo propiziatorio. Un'appliance proxyerà qualsiasi richiesta TCP, ma la inoltrerà al server solo se l'handshake a tre vie è completamente impostato.
SYN Caches: Two end-host defenses, called SYN caches and SYN cookies
(described later), operate by reducing the amount of state allocated
initially for a TCB generated by a received SYN, and putting off
instantiating the full state [8]. In a host that uses a SYN cache, a
hash table with a limited amount of space in each hash bucket is used
to store a subset of the data that would normally go into an allocated
TCB. If and when a handshake completing ACK is received, this data can
be moved into a full TCB; otherwise the oldest bucket at a particular
hash value can be reaped when needed. In Lemon's FreeBSD example [8],
the SYN cache entry for a half connection is 160 bytes, versus 736
bytes for a full TCB, and 15359 entries in the SYN cache are
supported.
The SYN cache data structure is robust to attackers attempting to
overflow its buckets because it uses the initiator's local port number
and some secret bits in the hash value. Because stacks are a more
effective data structure to search than a simple linked list, stacks
that use a SYN cache can have improved speed, even when not under
attack. Under Lemon's tests, during an active attack a host using a
SYN cache was able to establish legitimate connections with only about
a 15-percent increase in latency.
SYN Cookies: In contrast to the SYN cache approach, the SYN cookies
technique causes absolutely zero state to be generated by a received
SYN. Instead, the most basic data comprising the connection state is
compressed into the bits of the sequence number used in the SYN-ACK.
Since for a legitimate connection, an ACK segment will be received
that echoes this sequence number (actually the sequence number plus
one), the basic TCB data can be regenerated and a full TCB can safely
be instantiated by decompressing the Acknowledgement field. This
decompression can be effective even under heavy attack because there
is no storage load whatsoever on the listener, only a computational
load to encode data into the SYN-ACK sequence numbers. The downside is
that not all TCB data can fit into the 32-bit Sequence Number field,
so some TCP options required for high performance might be disabled.
Another problem is that SYN-ACKs are not retransmitted (because
retransmission would require state), altering the TCP synchronization
procedures from RFC 793.
The exact format of TCP SYN cookies is not an interoperability issue,
because they are only locally interpreted, and the format and
procedures for generation and validation can vary slightly among
implementations. Figure 5 depicts the general process of SYN cookie
generation and validation used by multiple implementations.
To compute the SYN-ACK sequence number (that is, the TCP cookie) when
using TCP cookies, a host first concatenates some local secret bits, a
data structure that contains the IP addresses and TCP ports, the
initial SYN sequence number, and some index data identifying the
secret bits. An MD5 digest is computed over all these bytes, and some
bits are truncated from the hash value to be placed in the SYN-ACK
sequence number. Because the sequence number is about a fourth the
size of the full hash value, this truncation is necessary, but
generally at least 3 bytes worth of the hash bits are used, meaning
that there should still be close to a 2^24 effort required to guess a
valid cookie without knowing the local secret bits. In addition to the
hash output, some of the cookie bits indicate a lower bound on the
Maximum Segment Size (MSS) that the SYN contained, and the index bits
identifying the local secret used within the hash.
To validate a SYN cookie, first the acknowledgement number in an
incoming ACK segment is decremented by 1 to retrieve the generated SYN
cookie. The valid value for the set of truncated hash bits is computed
based on the IP address pair, TCP port numbers, segment sequence
number minus one, and the value from the secret pool corresponding to
the index bits inside the cookie. If these computed hash bits match
those within the ACK segment, then a TCB is initialized and the
connection proceeds. The encoded MSS bound is used to set a
reasonable-sized MSS that is no larger than what was originally
advertised. This MSS is usually implemented as three bits whose code
points correspond to eight "commonly advertised" MSS values based on
typical link Maximum Transmission Units (MTUs) and header overheads.
Hybrid Approaches: A hybrid approach combines two or more of the
single defense techniques described previously. For instance, some
end-host operating systems implement both a large backlog and SYN
cookies, but enable SYN cookies only when the amount of the backlog
that is occupied exceeds some threshold, allowing them to normally
operate without the disadvantages of SYN cookies, but also allowing
them to fail over to the SYN-cookie behavior and be strongly protected
when an attack occurs.