1

以下は、Linux カーネルからのコードのスニペットです。syn-cookie に client の seq を含めます。このスキームの問題は、クライアントからの最初のパケットがドロップされた場合、2 番目のパケットで接続がリセットされることです。私の質問は、SYN Cookie にクライアントのシーケンス番号を含める必要があるのはなぜですか?

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));
}
4

1 に答える 1

1

sseq 番号はハッシュ操作に含まれており、Cookie により多くの状態情報が含まれています。複数のばらばらな情報が一緒に調理されると、ハッシュがより堅牢になるというのは一般的な概念です。そして、2 番目の syn ケースで conn がリセットされるという懸念については、そうです。さらに、syn Cookie は通常、サーバーが脅威にさらされていることが検出された場合にのみ有効になります。

syn-cookie の実装と、sseq 番号が入力パラメータの 1 つである理由については、こちらをお読みください。

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-4/syn_flooding_attacks.html

于 2013-10-04T06:28:23.043 に答える