SYN_RECV接続の数が少ないにもかかわらず、ログに「可能なSYNフラッディング」
最近、SYNフラッディングのために非常に遅い応答をするApacheサーバーがありました。これの回避策は、tcp_syncookies（net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf）を有効にすることでした。 あなたがより多くの背景が必要な場合、私はこれに関する質問をここに投稿しました。 syncookiesを有効にした後、約60秒ごとに/ var / log / messagesに次のメッセージが表示されるようになりました。 [84440.731929] possible SYN flooding on port 80. Sending cookies. Vinko Vrsalovicは、これがsynバックログがいっぱいになっていることを通知してくれたので、tcp_max_syn_backlogを4096に上げましたsysctl -w net.ipv4.tcp_synack_retries=3。これを行った後、頻度は低下しているようで、メッセージの間隔は約60〜180秒の間で変化しました。 次に、を発行しましたがsysctl -w net.ipv4.tcp_max_syn_backlog=65536、まだログにメッセージが記録されています。 このすべてを通して、（実行watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l'することによって）SYN_RECV状態の接続の数を監視してきましたが、それが約240を超えることはなく、バックログのサイズよりはるかに低くなりません。それでも、約512個のRed Hatサーバーがあります（このサーバーの制限はデフォルトの1024です）。 バックログのサイズを制限する他のtcp設定はありますか、または間違ったツリーを起動していますか？SYN_RECV接続の数はnetstat -tuna、バックログのサイズに相関する必要がありますか？ 更新 ここで合法的な接続を処理していると言えば、netstat -tuna|wc -l5000前後です。今日これを調査していて、last.fmの従業員からのこの投稿を見つけました。 また、syncookiesが有効になっている場合、tcp_max_syn_backlogは効果がないことも発見しました（このリンクのとおり） そのため、次のステップとして、sysctl.confで以下を設定します。 net.ipv4.tcp_syn_retries = 3 # default=5 net.ipv4.tcp_synack_retries = 3 …