zuntan02のはてなブログ

備忘録的なものです。時々職場の技術者ブログにも転記してますが、メインはこちらで。

メモ:kernel: possible SYN flooding on port 80. Sending cookies.

NewRelicで監視しているサーバから
Alert open: unable to ping hogehoge.jp on 'fugafuga'
(監視条件:Downtime:Alert when any ping URL is unresponsive for 1 minutes)
が届いてて、該当時間帯の/var/log/messagesを見ると以下のメッセージが確認された。

Feb xx xx:xx:xx fuga kernel: possible SYN flooding on port 80. Sending cookies.

こちらによれば
小岩以上アキバ未満~記憶のディザスター~: CentOS6などでdmesgにpossible SYN flooding on port(SYN flooding警告)が出た場合の対策方法を考えてみるテスト
「大量の正常アクセス、またはDoS攻撃」のどっちか、だそう。
→該当時間帯は確かにアクセス集中が来てて、これがSYN floodingと判定された?



アクセス集中の結果、待ち状態の接続が多くなり、OSがSYN flood attackを受けている可能性ありと判断して、アクセスをSending SYN cookies モードに変更したことが原因で、NewRelicからの監視がコケた、ということらしい。

【参考】

SYN flood - Wikipedia

該当機能の有効状態確認

cat /proc/sys/net/ipv4/tcp_syncookies
1←有効

上記状態となるトリガー

netstat -an | grep TIME_WAIT | wc -l
TIME_WAIT状態の接続が
/proc/sys/net/ipv4/tcp_max_syn_backlog
(デフォルト1024)の値よりも多いと発動
※timeoutの値は
/proc/sys/net/ipv4/tcp_fin_timeout
に設定されている。デフォルト60秒

【解決策】

監視サーバ側でどうにか対応?

NewRelic側は何らかの対応してくれることを祈るのみ

サーバ側のSending Cookie閾値を変えてしまう

tcp_max_syn_backlogの値を1024→32000
という豪快な解決策も提示されていたがやりたくないのでしばらく様子見……