SYN Cookie的原理和實現

 

 

 

 

 

本文主要內容：SYN Cookie的原理，以及它的內核實現。

內核版本：3.6

 

 

SYN Flood

 

下面這段介紹引用自[1].

SYN Flood是一種非常危險而常見的Dos攻擊方式。到目前為止，能夠有效防范SYN Flood攻擊的手段並不多，

SYN Cookie就是其中最著名的一種。

 

SYN Flood攻擊是一種典型的拒絕服務(Denial of Service)攻擊。所謂的拒絕服務攻擊就是通過進行攻擊，使受害主機或

網絡不能提供良好的服務，從而間接達到攻擊的目的。

SYN Flood攻擊利用的是IPv4中TCP協議的三次握手(Three-Way Handshake)過程進行的攻擊。

TCP服務器收到TCP SYN request包時，在發送TCP SYN + ACK包回客戶機前，TCP服務器要先分配好一個數據區專門

服務於這個即將形成的TCP連接。一般把收到SYN包而還未收到ACK包時的連接狀態稱為半打開連接(Half-open Connection)。

在最常見的SYN Flood攻擊中，攻擊者在短時間內發送大量的TCP SYN包給受害者。受害者(服務器)為每個TCP SYN包分配

一個特定的數據區，只要這些SYN包具有不同的源地址(攻擊者很容易偽造)。這將給TCP服務器造成很大的系統負擔，最終

導致系統不能正常工作。

 

SYN Cookie

 

SYN Cookie原理由D.J. Bernstain和Eric Schenk提出。

SYN Cookie是對TCP服務器端的三次握手做一些修改，專門用來防范SYN Flood攻擊的一種手段。它的原理是，在TCP服務器

接收到TCP SYN包並返回TCP SYN + ACK包時，不分配一個專門的數據區，而是根據這個SYN包計算出一個cookie值。這個

cookie作為將要返回的SYN ACK包的初始序列號。當客戶端返回一個ACK包時，根據包頭信息計算cookie，與返回的確認序列

號(初始序列號 + 1)進行對比，如果相同，則是一個正常連接，然后，分配資源，建立連接。

 

實現的關鍵在於cookie的計算，cookie的計算應該包含本次連接的狀態信息，使攻擊者不能偽造。

cookie的計算：

服務器收到一個SYN包，計算一個消息摘要mac。

mac = MAC(A, k);

MAC是密碼學中的一個消息認證碼函數，也就是滿足某種安全性質的帶密鑰的hash函數，它能夠提供cookie計算中需要的安全性。

在Linux實現中，MAC函數為SHA1。

A = SOURCE_IP || SOURCE_PORT || DST_IP || DST_PORT || t || MSSIND

k為服務器獨有的密鑰，實際上是一組隨機數。

t為系統啟動時間，每60秒加1。

MSSIND為MSS對應的索引。

 

實現

 

（1）啟用條件

判斷是否使用SYN Cookie。如果SYN Cookie功能有編譯進內核(CONFIG_SYN_COOKIE)，且選項

tcp_syncookies不為0，那么可使用SYN Cookie。同時設置SYN Flood標志(listen_opt->synflood_warned)。

/* Return true if a syncookie should be sent. */
bool tcp_syn_flood_action(struct sock *sk, const struct sk_buff *skb, const char *proto)
{
    const char *msg = "Dropping request";
    bool want_cookie = false;
    struct listen_sock *lopt;

#ifdef CONFIG_SYN_COOKIE
    if (sysctl_tcp_syncookies) { /* 如果允許使用SYN Cookie */
        msg = "Sending cookies";
        want_cookie = true;
        NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPREQQFULLDOCOOKIES);
    } else
#endif
        NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPREQQFULLDROP);

    lopt = inet_csk(sk)->icsk_accept_queue.listen_opt; /* 半連接隊列 */

    if (! lopt->synflood_warned) {
        lopt->synflood_warned = 1; /* 設置SYN Flood標志 */
        pr_info("%s: Possible SYN flooding on port %d. %s.  Check SNMP counters.\n",
                       proto, ntohs(tcp_hdr(skb)->dest), msg);
    }

    return want_cookie;
}

 

（2）生成cookie

計算SYN Cookie的值。

函數調用路徑：

tcp_v4_conn_request

        |--> cookie_v4_init_sequence

                          |--> secure_tcp_syn_cookie

/* Generate a syncookie. mssp points to the mss, which is returned rounded down to the
 * value encoded in the cookie.
 */

__u32 cookie_v4_init_sequence(struct sock *sk, struct sk_buff *skb, __u16 *mssp)
{
    const struct iphdr *iph = ip_hdr(skb);
    const struct tcphdr *th = tcp_hdr(skb);
    int mssind; /* mss index */
    const __u16 mss = *mssp;

    tcp_synq_overflow(sk); /* 記錄半連接隊列溢出的最近時間 */

    for (mssind = ARRAY_SIZE(msstab) - 1; mssind; mssind--)
        if (mss >= msstab[mssind])
            break;
    *mssp = msstab[mssind];

    NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_SYNCOOKIESSENT);

    return secure_tcp_syn_cookie(iph->saddr, iph->daddr, th->source, th->dest, ntohl(th->seq),
                      jiffies / (HZ * 60), mssind); /* 計算SYN Cookie的具體值 */
}

/* syncookie: remember time of last synqueue overflow */
static inline void tcp_synq_overflow(struct sock *sk)
{
    tcp_sk(sk)->rx_opt.ts_recent_stamp = jiffies;
}

/*
 * MSS Values are taken from the 2009 paper
 * 'Measuring TCP Maximum Segment Size' by S. Alcock and R. Nelson:
 * - values 1440 to 1460 accounted for 80% of observed mss values
 * - values outside the 536-1460 range are rare (<0.2%).
 *
 * Table must be sorted.
 */
static __u16 const msstab[] = {
    64,
    512,
    536,
    1024,
    1440,
    1460,
    4312,
    8960,
};

static __u32 secure_tcp_syn_cookie(__be32 saddr, __be32 daddr, __be16 sport, __be16 dport,
                                   __u32 sseq, __u32 count, __u32 data)
{
    /* Compute the secure sequence number.
     * The output should be:
     * HASH(sec1, saddr, sport, daddr, dport, sec1) + sseq + (count * 2^24) +
     *     (HASH(sec2, saddr, sport, daddr, dport, count, sec2) % 2^24).
     * Where sseq is their sequence number and count increases every minute by 1.
     * As an extra hack, we add a small "data" value that encodes the MSS into the second hash value.
     */
    return (cookie_hash(saddr, daddr, sport, dport, 0, 0) + sseq + (count << COOKIEBITS) +
              ((cookie_hash(saddr, daddr, sport, dport, count, 1) + data) & COOKIEMASK));

}

#define COOKIEBITS 24 /* Upper bits store count */
#define COOKIEMASK (((__u32) 1 << COOKIEBITS) - 1)
#define SHA_DIGEST_WORDS 5
#define SHA_WORKSPACE_WORDS 16

服務器的密鑰、SHA1計算。

__u32 syncookie_secret[2] [16 - 4 + SHA_DIGEST_WORDS];

static __init int init_syncookies(void)
{
    get_random_bytes(syncookie_secret, sizeof(syncookie_secret));
    return 0;
}

static DEFINE_PER_CPU(__u32 [16 + 5 + SHA_WORKSPACE_WORDS], ipv4_cookie_scratch);

static u32 cookie_hash(__be32 saddr, _be32 daddr, __be16 sport, __be16 dport, u32 count, int c)
{
    __u32 *tmp = __get_cpu_var(ipv4_cookie_scratch);

    memcpy(tmp + 4, syncookie_secret[c], sizeof(syncookie_secret[c])); /* c取值為0、1 */
    tmp[0] = (__force u32) saddr;
    tmp[1] = (__force u32) daddr;
    tmp[2] = ((__force u32) sport << 16) + (__force u32) dport;
    tmp[3] = count;

    sha_transform(tmp + 16, (__u8 *)tmp, tmp + 16 + 5); /* generate a 160-bit digest from 512-bit block */
    return tmp[17];
}

SHA1

安全哈希算法(Secure HASH Algorithm)主要適用於數字簽名。

對於長度小於2^64位的消息，SHA1會產生一個160位的消息摘要。當接收到消息的時候，這個消息摘要可以用來

驗證數據的完整性。在傳輸的過程中，數據可能會發生變化，那么這時候就會產生不同的消息摘要。

SHA1有如下特性：

1. 不可以從消息摘要中復原信息。

2. 兩個不同的消息不會產生同樣的消息摘要。

在Git中，也使用SHA1來標識每一次提交。

/* sha_transform - single block SHA1 transform
 * @digest: 160 bit digest to update
 * @data: 512 bits of data to hash
 * @array: 16 words of workspace (see note)
 *
 * This function generates a SHA1 digest for a single 512-bit block.
 * /
void sha_transform(__u32 *digest, const char *data, __u32 *array) {}

 

（3）保存TCP選項信息

tcp_v4_send_synack

        |--> tcp_make_synack

                       |--> cookie_init_timestamp

如果SYNACK段使用SYN Cookie，並且使用時間戳選項，則把TCP選項信息保存在SYNACK段中tsval的低6位。

/* When syncookies are in effect and tcp timestamps are enabled we encode tcp options
 * in the lower bits of the timestamp value that will be sent in the syn-ack.
 * Since subsequent timestamps use the normal tcp_time_stamp value, we must make
 * sure that the resulting initial timestamp is <= tcp_time_stamp.
 */
__u32 cookie_init_timestamp(struct request_sock *req)
{
    struct inet_request_sock *ireq;
    u32 ts, ts_now = tcp_time_stamp;
    u32 options = 0;
    ireq = inet_rsk(req);

    options = ireq->wscale_ok ? ireq->snd_wscale : 0xf;
    options |= ireq->sack_ok << 4;
    options |= ireq->ecn_ok << 5;

    ts = ts_now & ~TSMASK;
    ts |= options;

    if (ts > ts_now) {
        ts >>= TSBITS;
        ts--;
        ts <<= TSBITS;
        ts |= options;
    }
    return ts;
}

#define TSBITS 6
#define TSMASK (((__u32) 1 << TSBITS) - 1)

（4）驗證cookie

函數調用路徑：

tcp_v4_hnd_req

        |--> cookie_v4_check

                      |--> cookie_check

                                       |--> check_tcp_syn_cookie

 

SYN Cookie的設計非常巧妙， 我們來看看它是怎么驗證的。

首先，把ACK包的ack_seq - 1，得到原來計算的cookie。把ACK包的seq - 1，得到SYN段的seq。

cookie的計算公式為：

cookie = cookie_hash(saddr, daddr, sport, dport, 0, 0) + seq +

                (t1 << 24) + (cookie_hash(saddr, daddr, sport, dport, t1, 1) + mssind) % 24;

t1為服務器發送SYN Cookie的時間，單位為分鍾，保留在高12位。

mssind為MSS的索引(0 - 7)，保留在低24位。

 

現在可以反過來求t1：

t1 = (cookie - cookie_hash(saddr, daddr, sport, dport, 0, 0) - seq) >> 24; /* 高12位表示時間 */

t2為收到ACK的時間，t2 - t1 < 4分鍾，才是合法的。也就是說ACK必須在4分鍾內到達才行。

 

驗證完時間后，還需驗證mssind：

cookie -= (cookie_hash(saddr, daddr, sport, dport, 0, 0) - seq);

mssind = (cookie - cookie_hash(saddr, daddr, sport, dport, t1, 1)) % 24; /* 低24位 */

mssind < 8，才是合法的。

 

如果t1和mssind都是合法的，則認為此ACK是合法的，可以直接完成三次握手。

/* Check if a ack sequence number is a valid syncookie.
 * Return the decoded mss if it is, or 0 if not.
 */

static inline int cookie_check(struct sk_buff *skb, __u32 cookie)
{
    const struct iphdr *iph = ip_hdr(skb);
    const struct tcphdr *th = tcp_hdr(skb);
    __u32 seq = ntohl(th->seq) - 1; /* SYN的序號 */

    __u32 mssind = check_tcp_syn_cookie(cookie, iph->saddr, iph->daddr, th->source, th->dest,
                          seq, jiffies / (HZ * 60), COUNTER_TRIES);

    /* 如果不合法則返回0 */
    return mssind < ARRAY_SIZE(msstab) ? msstab[mssind] : 0;
}

/* 使用SYN Cookie時，ACK超過了這個時間到達，會被認為不合法。*/
/* This (misnamed) value is the age of syncookie which is permitted.
 * Its ideal value should be dependent on TCP_TIMEOUT_INIT and sysctl_tcp_retries1.
 * It's a rather complicated formula (exponential backoff) to compute at runtime so it's
 * currently hardcoded here.
 */
#define COUNTER_TRIES 4 /* 4分鍾 */

static __u32 check_tcp_syn_cookie(__u32 cookie, __be32 saddr, __be32 daddr, __be16 sport,
            __be16 dport, __u32 sseq, __u32 count, __u32 maxdiff)
{
    __u32 diff;

    /* Strip away the layers from the cookie, 剝去固定值的部分 */
    cookie -= cookie_hash(saddr, daddr, sport, dport, 0, 0) + sseq;

    /* Cookie is now reduced to (count * 2^24) + (hash % 2^24) */
    diff = (count - (cookie >> COOKIEBITS)) & ((__u32) -1 >> COOKIEBITS); /* 高12位是時間，單位為分鍾 */
    if (diff >= maxdiff)
        return (__u32)-1;

    /* Leaving the data behind，返回的是原來的data，即mssind */
    return (cookie - cookie_hash(saddr, daddr, sport, dport, count - diff, 1)) & COOKIEMASK;
}

 

（5）建立連接

接收到ACK后，SYN Cookie的處理函數為cookie_v4_check()。

首先要驗證cookie是否合法。

如果cookie是不合法的，返回監聽sk，會導致之后發送一個RST給客戶端。

如果cookie是合法的，則創建和初始化連接請求塊。接着為新的連接創建和初始化一個新的傳輸控制塊，

把它和連接請求塊關聯起來，最后把該連接請求塊鏈入全連接隊列中，等待accept()。

 

時間戳對SYN Cookie有着重要的意義，如果不支持時間戳選項，則通過SYN Cookie建立的連接就會

不支持大多數TCP選項。

struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb, struct ip_options *opt)
{
    struct tcp_options_received tcp_opt;
    const u8 *hash_location;
    struct inet_request_sock *ireq;
    struct tcp_request_sock *treq;
    struct tcp_sock *tp = tcp_sk(sk);
    const struct tcphdr *th = tcp_hdr(skb);
    __u32 cookie = ntohl(th->ack_seq) - 1;
    struct sock *ret = sk;
    struct request_sock *req;
    int mss;
    struct rtable *rt;
    __u8 rcv_wscale;
    bool ecn_ok = false;
    struct flowi4 fl4;

    if (! sysctl_tcp_syncookies || ! th->ack || th->rst)
        goto out;

    /* 驗證cookie的合法性，必須同時符合：
     * 1. 最近3s內有發生半連接隊列溢出。
     * 2. 通過cookie反算的t1和mssind是合法的。
     */
    if (tcp_synq_no_recent_overflow(sk) || (mss = cookie_check(skb, cookie)) == 0) {
        NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_SYNCOOKIESFAILED);
        goto out;
    }
    NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_SYNCOOKIESRECV);

    /* check for timestamp cookie support */
    memset(&tcp_opt, 0, sizeof(tcp_opt));

    /* 全面解析TCP選項，並保存到tcp_opt中 */
    tcp_parse_options(skb, &tcp_opt, &hash_location, 0, NULL);

    /* 如果有使用時間戳選項，則從ACK的tsecr中提取選項信息 */
    if (! cookie_check_timestamp(&tcp_opt, &ecn_ok))
        goto out;

    ret = NULL;
    /* 從緩存塊中分配一個request_sock實例，指定此實例的操作函數集為tcp_request_sock_ops */
    req = inet_reqsk_alloc(&tcp_request_sock_ops);
    if (! req)
        goto out;

    ireq = inet_rsk(req);
    treq = tcp_rsk(req);
    treq->rcv_isn = ntohl(th->seq) - 1; /* 客戶端的初始序列號 */
    treq->snt_isn = cookie; /* 本端的初始序列號 */
    req->mss = mss; /* 客戶端通告的MSS，通過解析cookie獲得 */
    ireq->loc_port = th->dest; /* 本端端口 */
    ireq->rmt_port = th->source; /* 客戶端端口 */
    ireq->loc_addr = ip_hdr(skb)->daddr; /* 本端IP */
    ireq->rmt_addr = ip_hdr(skb)->saddr; /* 客戶端IP */
    ireq->ecn_ok = ecn_ok; /* ECN選項，通過TS編碼獲得 */
    ireq->snd_wscale = tcp_opt.snd_wscale; /* 客戶端窗口擴大因子，通過TS編碼獲得 */
    ireq->sack_ok = tcp_opt.sack_ok; /* SACK允許選項，通過TS編碼獲得 */
    ireq->wscale_ok = tcp_opt.wscale_ok; /* 窗口擴大選項，通過TS編碼獲得 */
    ireq->tstamp_ok = tcp_opt.saw_tstamp; /* 時間戳選項，通過觀察ACK段有無攜帶時間戳 */
    req->ts_recent = tcp_opt.saw_tstamp ? tcp_opt.rcv_tsval : 0; /* 本端下個發送段的時間戳回顯值 */
    treq->snt_synack = tcp_opt.saw_tstamp ? tcp_opt.rcv_tsecr : 0; /* 本端發送SYNACK段的時刻 */

    /* We throwed the options of the initial SYN away, so we hope the ACK carries the same options
     * again (see RFC1122 4.2.3.8)
     * 通過ACK段，獲取IP選項。
     */
    if (opt && opt->optlen) {
        int opt_size = sizeof(struct ip_options_rcu) + opt->optlen;
        ireq->opt = kmalloc(opt_size, GFP_ATOMIC);

        if (ireq->opt != NULL && ip_options_echo(&ireq->opt->opt, skb)) {
            kfree(ireq->opt);
            ireq->opt = NULL;
        }
    }

    /* SELinux相關 */
    if (security_inet_conn_request(sk, skb, req)) {
        reqsk_free(req);
        goto out;
    }

    req->expires = 0UL; /* SYNACK的超時時間 */
    req->retrans = 0; /* SYNACK的重傳次數 */

    /* We need to lookup the route here to get at the correct window size.
     * We should better make sure that the window size hasn't changed since we
     * received the original syn, but I see no easy way to do this.
     * 查找路由緩存。
     */
    flowi4_init_output(&fl4, 0, sk->sk_mark, RT_CONN_FLAGS(sk), RT_SCOPE_UNIVERSE,
        IPPROTO_TCP, inet_sk_flowi_flags(sk), (opt && opt->srr) ? opt->faddr : ireq->rmt_addr,
        ireq->loc_addr, th->source, th->dest);
    security_req_classify_flow(req, flowi4_to_flowi(&fl4));
    rt = ip_route_output_key(sock_net(sk), &fl4);
    if (IS_ERR(rt)) {
        reqsk_free(req);
        goto out;
    }

    /* Try to redo what tcp_v4_send_synack did. */
    req->window_clamp = tp->window_clamp ? : dst_metric(&rt->dst, RTAX_WINDOW);

    /* 獲取接收窗口的初始值，窗口擴大因子和接收窗口的上限 */
    tcp_select_initial_window(tcp_full_space(sk), req->mss, &req->rcv_wnd, &req->window_clamp,
        ireq->wscale_ok, &rcv_wscale, dst_metric(&rt->dst, RTAX_INITRWND));
    ireq->rcv_wscale = rcv_wscale;

    /* 到了這里，三次握手基本完成。
     * 接下來為新的連接創建和初始化一個傳輸控制塊，並把它和連接請求塊關聯起來。
     * 最后把該連接請求塊移入全連接隊列中，等待accept()。
     */
    ret = get_cookie_sock(sk, skb, req, &rt->dst);

    /* ip_queue_xmit() depends on our flow being setup
     * Normal sockets get it right from inet_csk_route_child_sock()
     */
    if (ret)
        inet_sk(ret)->cork.fl.u.ip4 = fl4;

out:
    return ret;
}

/* RFC 1122 initial RTO value, now used as a fallback RTO for the initial data
 * transmssion if no valid RTT sample has been accquired, most likely due to
 * retrans in 3WHS.
 */
#define TCP_TIMEOUT_FALLBACK ((unsigned) (3 * HZ))

/* syncookies: no recent synqueue overflow on this listening socket?
 * 如果最近3s內沒有發生半連接隊列溢出，則為真。
 */
static inline bool tcp_synq_no_recent_overflow(const struct sock *sk)
{
    unsigned long last_overflow = tcp_sk(sk)->rx_opt.ts_recent_stamp;
    return time_after(jiffies, last_overflow + TCP_TIMEOUT_FALLBACK);
}

 

如果SYNACK段使用SYN Cookie，並且使用時間戳選項，則把TCP選項信息保存在SYNACK段中tsval的低6位。

所以，現在收到ACK后，可以從ACK段的tsecr中提取出這些選項。

/* When syncookies are in effect and tcp timestamps are enabled we stored addtional tcp
 * options in the timestamp.
 * This extracts these options from the timestamp echo.
 * The lowest 4 bits store snd_wscale.
 * next 2 bits indicate SACK and ECN support.
 * return false if we decode an option that should not be.
 */
bool cookie_check_timestamp(struct tcp_options_received *tcp_opt, bool *ecn_ok)
{
    /* echoed timestamp, lowest bits contain options */
    u32 options = tcp_opt->rcv_tsecr & TSMASK;

    /* 如果ACK沒有攜帶時間戳，則把tcp_opt中的tstamp_ok、sack_ok、wscale_ok
     * snd_wscale和cookie_plus置零。
     */
    if (! tcp_opt->saw_tstamp) {
        tcp_clear_options(tcp_opt);
        return true;
    }

    if (! sysctl_tcp_timestamps)
        return false;

    tcp_opt->sack_ok = (options & (1 << 4)) ? TCP_SACK_SEEN : 0;
    *ecn_ok = (options >> 5) & 1;

    if (*ecn_ok && ! sysctl_tcp_ecn)
        return false;

    if (tcp_opt->sack_ok && ! sysctl_tcp_sack)
        return false;

    if ((options & 0xf) == 0xf)
        return true; /* no window scaling. */

    tcp_opt->wscale_ok = 1;
    tcp_opt->snd_wscale = options & 0xf;
    return sysctl_tcp_window_scaling != 0;
}

 

為新的連接創建和初始化一個傳輸控制塊，然后把完成三次握手的req和新sock關聯起來，

並把該連接請求塊移入全連接隊列中。

static inline struct sock *get_cookie_sock(struct sock *sk, struct sk_buff *skb,
     struct request_sock *req, struct dst_entry *dst)
{
    struct inet_connection_sock *icsk = inet_csk(sk);
    struct sock *child;

    /* 為新的連接創建和初始化一個傳輸控制塊。
     * 對於TCP/IPv4，實例為ipv4_specific，調用tcp_v4_syn_recv_sock()
     */
    child = icsk->icsk_af_ops->syn_recv_sock(sk, skb, req, dst);

    if (child)
        /* 把完成三次握手的連接請求塊，和新的sock關聯起來，並把它移入全連接隊列中。*/
        inet_csk_reqsk_queue_add(sk, req, child);
    else
        reqsk_free(req);

    return child;
}

static inline void inet_csk_reqsk_queue_add(struct sock *sk, struct request_sock *req, struct sock *child)
{
    reqsk_queue_add(&inet_csk(sk)->icsk_accept_queue, req, sk, child);
}

 

把完成三次握手的連接請求塊，和新的sock關聯起來，並把它移入全連接隊列中，等待被accept()。

static inline void reqsk_queue_add(struct request_sock_queue *queue, struct request_sock *req,
      struct sock *parent, struct sock *child)
{
    req->sk = child; /* 連接請求塊request_sock，關聯了一個新sock */
    sk_acceptq_added(parent); /* 監聽sock的全連接隊列中的連接請求個數加一 */

    /* 全連接隊列是一個FIFO隊列，把req加入到隊列尾部 */
    if (queue->rskq_accept_head == NULL)
        queue->rskq_accept_head = req;
    else
        queue->rskq_accept_tail->dl_next = req;

    queue->rskq_accept_tail = req;
    req->dl_next = NULL;
}

static inline void sk_acceptq_added(struct sock *sk)
{
    sk->sk_ack_backlog++;
}

 

評價

 

SYN Cookie技術由於在建立連接的過程中不需要在服務器端保存任何信息，實現了無狀態的三次握手，從而有效的

防御了SYN Flood攻擊。但是該方法也存在一些弱點。由於cookie的計算只涉及到包頭部分信息，在建立連接的過程

中不在服務器端保存任何信息，所以失去了協議的許多功能，比如超時重傳。此外，由於計算cookie有一定的運算量，

增加了連接建立的延遲時間，因此，SYN Cookie技術不能作為高性能服務器的防御手段。通常采用動態資源分配機制，

當分配了一定的資源后再采用cookie技術，Linux就是這樣實現的。還有一個問題是，當我們避免了SYN Flood攻擊的

同時，也提供了另一種拒絕服務攻擊方式，攻擊者發送大量的ACK報文，服務器忙於計算驗證。盡管如此，在預防

SYN Flood供給方面，SYN Cookie技術仍然是有效的（引用自[1]）。

 

擴展

 

Linux內核中的SYN Cookie機制主要的功能是防止本機遭受SYN Flood攻擊。

SYN Cookie Firewall利用SYN Cookie的原理，在內網和外網之間實現TCP三次握手過程的代理(proxy)。

一些SYN攻擊的防火牆也是基於SYN Cookie，只是把這個功能移動到內核之外的代理服務器上。

 

Reference

 

[1]. https://www.ibm.com/developerworks/cn/linux/l-syncookie/