また徒労日記のWebサーバがスローダウンしました。事例として経過をメモしておきます。
発生は今日の15:50
以前に
iPhoneが探すapple-touch-icon.pngを用意(サイト不調のお詫び)徒労日記 | 徒労日記
GoogleAnalyticsで観る限りそんなに同時アクセスは無いので一種の熱病にかかったんじゃないかと思いました。
と表現していたサーバの熱病がまた起きました。
確認すると正常時は(左側の空きメモリ：kbmemfreeに注目)
$ sar -r Linux 2.6.32-042stab092.2 (dti-vps-srv931) 2014年10月04日 _x86_64_ (32 CPU) 00時00分02秒 kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit 00時10分01秒 2540324 1653980 39.43 0 136092 0 0.00 00時20分01秒 2424548 1769756 42.19 0 136392 0 0.00 00時30分01秒 2453444 1740860 41.51 0 137008 0 0.00 中略 14時10分01秒 2620800 1573504 37.52 0 135176 0 0.00 14時20分01秒 2845036 1349268 32.17 0 136216 0 0.00 14時30分01秒 3018136 1176168 28.04 0 137560 0 0.00 14時40分01秒 2918172 1276132 30.43 0 138724 0 0.00 14時50分01秒 2541536 1652768 39.41 0 139264 0 0.00
だったものが、今日の15時50分を境に
15時40分01秒 2101212 2093092 49.90 0 144260 0 0.00 15時50分02秒 307020 3887284 92.68 0 17616 0 0.00 16時00分02秒 52904 4141400 98.74 0 6948 0 0.00 16時10分02秒 21344 4172960 99.49 0 8268 0 0.00 16時20分01秒 36176 4158128 99.14 0 8480 0 0.00 16時30分01秒 643368 3550936 84.66 0 49140 0 0.00 16時40分02秒 214712 3979592 94.88 0 8448 0 0.00 16時50分02秒 522016 3672288 87.55 0 51880 0 0.00 中略 18時20分01秒 5516 4188788 99.87 0 6964 0 0.00 18時30分02秒 4664 4189640 99.89 0 14600 0 0.00 18時40分02秒 7392 4186912 99.82 0 9668 0 0.00 18時50分01秒 1312 4192992 99.97 0 7432 0 0.00 19時00分02秒 1136 4193168 99.97 0 7024 0 0.00 19時10分01秒 1248 4193056 99.97 0 900 0 0.00
空きメモリを食い尽くし、スワップが3GB近くまで使用されている状態でした。家の回線やiPhoneからアクセスしても死んでは居ないけど極端に応答の無い状態。遅いってレベルではなくて。
最初はApacheの設定を疑う
前回と同じhttpdのパラメータから疑い始めました。でもMaxClientをいくら下げても遅いのは変わらず。ググってもみんなこれで直った！って書いてる人ばかりなんですけどね・・・。今回もGoogle Analysticsのリアルタイムサマリーは大した人数を示していません。
とりあえずhttpd1個あたりのメモリ使用量(top -cのRES)が多すぎるので、急いで
- httpd.confから余計なLoadModulesを削除
（参考サイト：Apacheの不要モジュールを外してWordPress(ワードプレス)を高速化する | CONETA.JP) - php.iniのmemory_limit = を128Mから80Mへ。
を実施。少しメモリ使用量は減りましたが、サーバの無反応っぷりは相変わらず。
これじゃない。
アタックされてる？？
.phpへの不正アクセス？
ひとりぶろぐさんの記事「WordPressが重くてサーバが落ちる件、ブルートフォースアタック対策で正常化」を思い出してaccess.logをチェックしましたが、特段phpへのアクセスは無し。
これでもない。
レイヤ7で問題ないとすると、レイヤ３以下の話？？
そもそもと思ってtcpdump
Webサーバは虫の息なことにもかかわらず
sudo tcpdump port 80
したらものすごい速度でログが流れだしました。ゲリラ豪雨の様に落ちるログを死んだ魚みたいな目で眺めていると、特定のIPが多く出てくる事に気が付きました。パラパラ漫画の要領で(伝わるかなｺﾚ(‘A`)
いいチェック方法は無いかと探すと、iptablesでサーバへの攻撃をブロックする方法 ≪ Iptables ≪ セキュリティ ≪ ソフトウェアのインストールと設定 ≪ Linux 大学にていいコマンドを発見。netstatコマンドの結果を整形して、どのIPからのアクセスが多いか表示する方法です。
$ sudo netstat -anp |grep 'tcp\|udp' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
1 xxx.xxx.xxx.xxx
2 yyy.yyy.yyy.yyy
7 0.0.0.0
58 154.35.160.123
238ダントツに怪しい”154.35.160.123″が。
sudo tcpdump port 80 | grep -v 154.35.160.123
試しに↑すると大分まともなダンプ結果になるのでビンゴっぽい。
このアドレスが誰なのかドメイン/IPアドレス【whois情報検索】で調べましたが逆引き結果無し。
いい加減困ってるのでiptablesでブロックする事にしました。
$ sudo iptables -I INPUT -s 154.35.160.123 -p tcp -m tcp --dport 80 -j DROP $ sudo /etc/init.d/iptables save $ sudo /etc/init.d/iptables restart
最初はプロトコルもポートも指定しないでallでiptablesに入れましたがうまくブロックしてくれませんでした。”-p tcp -m tcp –dport 80″を入れる必要が有るようです。
この他２つほどの怪しいホストと、その他アタックへのブロック定義を追加してサーバアクセスが復帰しました。ただ一時的な対処療法だし、もしかすると相手が飽きてアクセスをやめただけかもしれません。
別なIP使ってくるでしょうから、denyリストの動的更新とか、まじめにiptablesを考えないとダメそうです。はぁ。