muninの「Connections through firewall」を見ているとEstablished（黄緑）が長期間残っています。今のアクセス数では特に対処する必要もないのですが、気持ち悪いので対処してみます。
nf_conntrackを調べてみる
muninの「Connections through firewall」がチェックしている/proc/net/nf_conntrackを調査してみます。
dport=80が6本接続されたままになっています。本ブログはhttp(80)をhttps(443)に強制転送かけているので、通常のクライアントはport80が443に切り替わり80は接続断となるはず。
# cat /proc/net/nf_conntrack |grep EST ipv4 2 tcp 6 373144 ESTABLISHED src=95.7.68.32 dst=157.7.142.114 sport=57316 dport=80 src=157.7.142.114 dst=95.7.68.32 sport=80 dport=57316 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 tcp 6 299 ESTABLISHED src=203.0.113.86 dst=157.7.142.114 sport=63482 dport=22 src=157.7.142.114 dst=203.0.113.86 sport=22 dport=63482 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 tcp 6 373145 ESTABLISHED src=95.7.68.32 dst=157.7.142.114 sport=57329 dport=80 src=157.7.142.114 dst=95.7.68.32 sport=80 dport=57329 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 tcp 6 373144 ESTABLISHED src=95.7.68.32 dst=157.7.142.114 sport=57322 dport=80 src=157.7.142.114 dst=95.7.68.32 sport=80 dport=57322 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 tcp 6 373143 ESTABLISHED src=95.7.68.32 dst=157.7.142.114 sport=57306 dport=80 src=157.7.142.114 dst=95.7.68.32 sport=80 dport=57306 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 tcp 6 373145 ESTABLISHED src=95.7.68.32 dst=157.7.142.114 sport=57338 dport=80 src=157.7.142.114 dst=95.7.68.32 sport=80 dport=57338 [ASSURED] mark=0 secmark=0 use=2
この接続元IPアドレスでhttpdログを確認するとUserAgentにFirefox/40.1のフレーズがあります。このUA、個人的にはBOT、特にWordPressのブルートフォース攻撃ツールだと思ってますが、本症状が発生するのはこのIPのみなので直接の関係性はなさそうです。
ひとまず異常に長いESTABLISHEDを短くしてセッションを早めに開放する対処をしてみようと思います。
nf_conntrack_tcp_timeout_establishedを調整する
とは言ったものの、どのKernelパラメータをいじればいいのか分かっていないので、ひとまず/proc/sys/net/netfilter
まわりを確認してみます。
# cd /proc/sys/net/netfilter # ls -l nf_conntrack_acct nf_conntrack_log_invalid nf_conntrack_tcp_timeout_last_ack nf_conntrack_buckets nf_conntrack_max nf_conntrack_tcp_timeout_max_retrans nf_conntrack_checksum nf_conntrack_tcp_be_liberal nf_conntrack_tcp_timeout_syn_recv nf_conntrack_count nf_conntrack_tcp_loose nf_conntrack_tcp_timeout_syn_sent nf_conntrack_events nf_conntrack_tcp_max_retrans nf_conntrack_tcp_timeout_time_wait nf_conntrack_events_retry_timeout nf_conntrack_tcp_timeout_close nf_conntrack_tcp_timeout_unacknowledged nf_conntrack_expect_max nf_conntrack_tcp_timeout_close_wait nf_conntrack_udp_timeout nf_conntrack_generic_timeout nf_conntrack_tcp_timeout_established nf_conntrack_udp_timeout_stream nf_conntrack_icmp_timeout nf_conntrack_tcp_timeout_fin_wait nf_log
timeoutに関係する設定を一通り確認してみると・・・nf_conntrack_tcp_timeout_establishedが該当しそうです。
# cd /proc/sys/net/netfilter/ # cat nf_conntrack_tcp_timeout_close 10 # cat nf_conntrack_tcp_timeout_close_wait 60 # cat nf_conntrack_tcp_timeout_established 432000 # cat nf_conntrack_tcp_timeout_fin_wait 120 # cat nf_conntrack_tcp_timeout_last_ack 30 # cat nf_conntrack_tcp_timeout_max_retrans 300 # cat nf_conntrack_tcp_timeout_syn_recv 60 # cat nf_conntrack_tcp_timeout_syn_sent 120 # cat nf_conntrack_tcp_timeout_time_wait 120 # cat nf_conntrack_tcp_timeout_unacknowledged 300 # cat nf_conntrack_udp_timeout 30 # cat nf_conntrack_udp_timeout_stream 180 #
432000秒=5日間、ESTABLISHEDは残るってことですね。何を想定した設定なのかはわかりませんが、デフォルトでは随分と長い間セッションを残しておくのですね。Webサーバには長すぎなので、根拠はありませんが1時間=3600秒に設定変更してみます。
# vi /etc/sysctl.conf
+ net.netfilter.nf_conntrack_tcp_timeout_established = 3600
# sysctl -p
# cat /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established
3600
nf_conntrack_tcp_timeout_establishedを変更しても既存のセッションには影響しない
nf_conntrack_tcp_timeout_establishedの変更直後にnf_conntrackを確認してみました。
3行目を見ると変更後のアクセスは3600からカウントダウンしていることがわかりますが、元々のセッションは37万秒のまま。既存のセッションには影響しないようですね。iptables再起動で強制的にセッションを切るのも手ですが、あと4日程度待ってみることにします。
# cat /proc/net/nf_conntrack |grep EST ipv4 2 tcp 6 372274 ESTABLISHED src=95.7.68.32 dst=157.7.142.114 sport=57316 dport=80 src=157.7.142.114 dst=95.7.68.32 sport=80 dport=57316 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 tcp 6 299 ESTABLISHED src=203.0.113.86 dst=157.7.142.114 sport=63482 dport=22 src=157.7.142.114 dst=203.0.113.86 sport=22 dport=63482 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 tcp 6 3599 ESTABLISHED src=89.145.95.70 dst=157.7.142.114 sport=48311 dport=443 src=157.7.142.114 dst=89.145.95.70 sport=443 dport=48311 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 tcp 6 372275 ESTABLISHED src=95.7.68.32 dst=157.7.142.114 sport=57329 dport=80 src=157.7.142.114 dst=95.7.68.32 sport=80 dport=57329 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 tcp 6 372274 ESTABLISHED src=95.7.68.32 dst=157.7.142.114 sport=57322 dport=80 src=157.7.142.114 dst=95.7.68.32 sport=80 dport=57322 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 tcp 6 372273 ESTABLISHED src=95.7.68.32 dst=157.7.142.114 sport=57306 dport=80 src=157.7.142.114 dst=95.7.68.32 sport=80 dport=57306 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 tcp 6 372275 ESTABLISHED src=95.7.68.32 dst=157.7.142.114 sport=57338 dport=80 src=157.7.142.114 dst=95.7.68.32 sport=80 dport=57338 [ASSURED] mark=0 secmark=0 use=2
4日後のnf_conntrack
セッションが切れる時間の前にnf_conntrackを確かめてみました。順調にカウントダウンしています。
# cat /proc/net/nf_conntrack |grep EST ipv4 2 tcp 6 559 ESTABLISHED src=95.7.68.32 dst=157.7.142.114 sport=57316 dport=80 src=157.7.142.114 dst=95.7.68.32 sport=80 dport=57316 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 tcp 6 299 ESTABLISHED src=203.0.113.86 dst=157.7.142.114 sport=50380 dport=50022 src=157.7.142.114 dst=203.0.113.86 sport=50022 dport=50380 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 tcp 6 560 ESTABLISHED src=95.7.68.32 dst=157.7.142.114 sport=57329 dport=80 src=157.7.142.114 dst=95.7.68.32 sport=80 dport=57329 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 tcp 6 559 ESTABLISHED src=95.7.68.32 dst=157.7.142.114 sport=57322 dport=80 src=157.7.142.114 dst=95.7.68.32 sport=80 dport=57322 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 tcp 6 558 ESTABLISHED src=95.7.68.32 dst=157.7.142.114 sport=57306 dport=80 src=157.7.142.114 dst=95.7.68.32 sport=80 dport=57306 [ASSURED] mark=0 secmark=0 use=2 ipv4 2 tcp 6 560 ESTABLISHED src=95.7.68.32 dst=157.7.142.114 sport=57338 dport=80 src=157.7.142.114 dst=95.7.68.32 sport=80 dport=57338 [ASSURED] mark=0 secmark=0 use=2
その後の「Connections through firewall」
下記グラフの20:40以降を見るとわかるように、Establishedが残る状態が発生しても1時間で切断されることを確認しました。
