DDOS攻撃を防ぐために、Linuxボックスで/ proc/sys/net/ipv4/tcp_syncookiesの値を1に設定してTCP syncookies。
ただし、次のURLを見ると、 http://ckdake.com/content/2007/disadvantages-of-tcp-syn-cookies.html
Tcp_syncookiesを有効にすると、大きなウィンドウの管理を含むtcp機能の半分が無効になり、パフォーマンスが低下する可能性があることがわかります。
他の場所で、syn cookieの目的の一部がtcp synバックログバッファーを(/ proc/sys/net/ipv4/tcp_max_syn_backlogを介して)上限を超えて拡張し、パケットがドロップしないようにすることで読んだことがあります。
Syn Cookieを無効にして、TCPを最大限に活用し、サーバーをより高速に実行し、DDOS攻撃を受けないようにしたい。シンバッファと最大接続を簡単に増やすことができますが、高すぎるとメモリ不足になる可能性があると思います。
誰かがDDOSに攻撃される可能性のない重いサーバーでsyn cookieに代わる優れた方法を持っていますかTCPの機能を楽しみ、ユーザーに非常に高速にコンテンツを提供したい。
どうやら、tcp_syncookiesは不利な点よりも多くの利点をもたらします。
ランダムなブログの典型的な推測の代わりに、おそらく「 ソース 」を参照することができます:
IPv6と最新のTCP=オプションスキームの更新により、syncookiesは、やや難解なネットワークセキュリティニッチの甘い救済を提供し続けるように準備されているように見えます。
リンクされた記事 はいくつかの実験を引用し、いくつかの結論を引き出します:
Willy Tarreau:AMD LX800でmax_syn_backlogを63000にしてHTTPリバースプロキシでテストしたところ、250ヒット/秒の正当なトラフィックを8000 SYN /秒のノイズで注入しました。[..] SYN Cookieがない場合、平均応答時間は約1.5秒で不安定(再送信のため)、CPUは60%に設定されています。 SYN Cookieを有効にすると、応答時間は12〜15ミリ秒にまで低下しましたが、CPU使用率は70%に跳ね上がりました。違いは、より高い正当なトラフィックレートで現れます。
Ross Vandegrift:SYNフラッドがない場合、サーバーはフラッディングモードでhttpingを介して測定された毎秒750のHTTPリクエストを処理します。 1024のデフォルトのtcp_max_syn_backlogを使用すると、2つのスレッドのsynフラッドによる受信クライアント接続を簡単に防ぐことができます。 tcp_syncookiesを有効にすると、接続処理が毎秒最大725フェッチに戻ります。
このデータは、syncookieの継続的な価値を説得力のある方法でサポートしており、その地位がその日に勝利したようです。 IPv6 syncookieパッチがネットワーク2.6.26開発ツリー内のキューに追加されました。
また、CentOSの documentation によると、これは、おそらく正当なトラフィックの中断を回避するために、適応的な方法で使用されます。
Iftcp_max_syn_backlogに設定された数に達した場合、このパラメーターが作動し、接続が決して来ないACKを待っている接続が原因でサーバーに到達できないことはありません。
Ubuntu 10.04のデフォルトの「sysctl.d/10-network-security.conf」設定は次のとおりです。
# Turn on SYN-flood protections. Starting with 2.6.26, there is no loss
# of TCP functionality/features under normal conditions. When flood
# protections kick in under high unanswered-SYN load, the system
# should remain more stable, with a trade off of some loss of TCP
# functionality/features (e.g. TCP Window scaling).
net.ipv4.tcp_syncookies=1