わたしが運用している web サーバが攻撃を受けて httpd プロセスが落ちてしまった可能
性がありまして，詳しいことを教えてくださる方，よろしくお願いします。
文字数制限により，状況の詳細に関しては別途投稿します。
知りたいことは以下です。
・「ココを見なさい」 というアドバイス
・攻撃の手法
・攻撃が httpd に具体的にどのような影響を与えたため, httpd が落ちたのか
例:
- 攻撃により CPU/メモリリソースを圧迫したため, httpd が落ちた
- /var/log/secure に残っている攻撃 (sshd に対する攻撃) とは別に，
httpd の脆弱性に対して攻撃を受けたため, httpd が落ちた
・対策
・あるいは, httpd が落ちたほかの原因の可能性
状況の詳細です。
・iPhone でソーシャルゲームをリリースし, ゲームのコンテンツサーバとして
web サーバ (apache + PHP + mysql) を稼働している。
・OS は Cent OS 5.8 final.
・httpd は httpd-2.2.3-65.el5.centos
・ホストA で httpd を稼働し, ホストB で mysqld を稼働している状態。
今回は ホストA の httpd プロセスが死んだ. ホストB には影響はなかった模様。
・access_log から, 9/16 10:15 ごろに httpd プロセスが死んだらしい
・/var/log/httpd/access_log
/var/log/httpd/error_log
/var/log/messages
には特に手掛かりになるような怪しいところはなかった
・10:11 ～ 10:13 のあいだに, /var/log/secure に 30 回程度の攻撃を受けた形跡アリ
下記のようなログが 30回程度繰り返されていました。
Sep 16 10:11:59 v2206 sshd[12359]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.141.217.150 user=root
Sep 16 10:12:01 v2206 sshd[12359]: Failed password for root from 121.141.217.150 port 56939 ssh2
Sep 16 10:12:01 v2206 sshd[12360]: Received disconnect from 121.141.217.150: 11: Bye Bye
Sep 16 10:12:13 v2206 sshd[12368]: Invalid user oracle from 121.141.217.150
Sep 16 10:12:13 v2206 sshd[12369]: input_userauth_request: invalid user oracle
Sep 16 10:12:13 v2206 sshd[12368]: pam_unix(sshd:auth): check pass; user unknown
Sep 16 10:12:13 v2206 sshd[12368]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=121.141.217.150
Sep 16 10:12:15 v2206 sshd[12368]: Failed password for invalid user oracle from 121.141.217.150 port 58115 ssh2
Sep 16 10:12:15 v2206 sshd[12369]: Received disconnect from 121.141.217.150: 11: Bye Bye
※ 121.141.217.150 は韓国の IP のようです。晒します。
No.4
966
247
1000pt
Apache Http Server : List of security vulnerabilities
上記ページは、Apache httpd で DoS を引き起こす脆弱性で、確認されているもののリストです。
もし、httpd の停止が、リモートから httpd を直接停止させるようなものであれば、上記リストのいずれかが使われた可能性はあります。ただ、「httpd-2.2.3-65.el5.centos」がリリースされたのは、今年の 6 月で、パッケージの changelog を見ると、今年の 2 月に CVE-2012-0053, CVE-2012-0031, CVE-2011-3607 に対する fix がなされていることから、少なくとも、今年の２月の時点で、クリティカルな問題には対応されている事が期待されます。
もちろん、全ての脆弱性が fix されている訳ではありませんが、逆に、無条件でリモートからサービスを落とせるとは、かなり考えづらいです。
なので、
といった事が考えられます。
sshd へのアクセスを気にされていましたが、sshd へのブルートフォースアタックは日常茶飯事で、そういった記録が /var/log/secure にあること自体は普通です。
ただ、むしろ気になるのは、
下記のようなログが 30回程度繰り返されていました。
たかだか 30 回、というのが気になります。sshd へのブルートフォースアタックは、sshd ポートが開いていると分かると、平気で何時間もアクセスを繰り返します。下手すると半日ぐらい続きます。つまり「30 回」というのが、ブルートフォースに失敗したと考えるには、少なすぎます。もし、sshd へのブルートフォースアタックに成功して、何らかの特権奪取に成功したのであれば、sshd へのログイン成功のログは消去されていると思われますし、httpd を停止する事も可能です。
sshd へのブルートフォースアタックは、手当たり次第に行われていて、踏み台として使うような、「駒」となるホストを得る事が目的な事が多く、httpd の停止は目的ではなく、「駒」にするための作業をしている最中にへまをして止めた、という可能性はあります。
ただ、httpd のバージョンから考えると、きちんとアップデートされているようなので、仮に ssh のブルートフォースアタックに成功しても、特権を取得できるかは疑問です。もし、httpd だけアップデートしているような状況であれば、root の特権を取られる可能性は否定できません。
とりあえず、与えられた情報から推測出来るのは、こんなところです。ssh のブルートフォースアタックが成功した可能性は否定できませんが、きちんとアップデートされていて、おかしな設定をしていなければ、httpd の停止に至るには、ちょっと難しいです。
余談になりますが、可能であれば、ssh を公開鍵認証のみにする事をおすすめします。こうすれば、パスワード認証によるブルートフォースアタックが成功する事はなくなります。
No.1
135391198
http://ja.wikipedia.org/wiki/DoS%E6%94%BB%E6%92%83
http://www.chuu-information.com/security/attack_16.html
SYN Flood攻撃対策
・SYNFloodプロテクション機能を持つOSやファイアウォールを用いる。
・コネクションウェイトタイムアウトを短くする。
・SYNパケットの帯域制限を行う。
smurf攻撃対策
・ルータやファイアウォールでICMPパケットを遮断する。
・ブロードキャスト宛のパケットを遮断する。
DDos攻撃対策
・十分な帯域をもつネットワークを使用する。
・サーバやネットワーク機器の処理能力を増強する。
ご回答ありがとうございました。
1. 本回答は
「ログに xx があるので，○○攻撃である」
というような，実証に基づいたご回答なのでしょうか ?
それとも
「web サーバが攻撃を受けたのならば，SYN Flood / smurf / DDos のどれかの可能性がある」
というような消極的な可能性を指示するご回答なのでしょうか ?
2. SYN Flood / smurf / DDos 攻撃を受けた場合，なんらかのログは残るのでしょうか。
3. SYN Flood / smurf / DDos 攻撃で，当該ホストの httpd プロセスだけを殺す，
ということができるのでしょうか ?
4. 攻撃者の心理を考えてみましょう。
攻撃者は，まず当該ホストへの (sshd で) 侵入を試みています。
で，侵入ができなかったからといって，腹いせに SYN Flood / smurf / DDos 攻撃でホストをダウンさせるようなことをするでしょうか ?
攻撃者が SYN Flood / smurf / DDos 攻撃を用いたとすると，
「見知らぬホストを，とりあえずサービス停止させるような攻撃をした」
という，愉快犯的な，というか，場当たり的な，というか, 非常にいい加減な，「とにかく相手を困らせてやれ」 的な攻撃を受けたことになります。
※ 本サービスは，一般的に公序良俗に基づいた，ノンポリシーの，要するに他人から恨みを買うようなサービスではありません。
そのような「性悪説的な」，「お馬鹿な」 攻撃者がそうそう居るものなのでしょうか ?
普通はIPアドレスを順にチェックしていきます。
それで 攻撃できそうなところみたいだから練習として攻撃されたかもしれません。
ま対策しか書かなかったですけど たいして 何もできないですね。
本格的に攻撃されたら どこも 持ちません。
No.2
1728320
100pt
エラーログから、Webが攻撃を受けたのではなく、SSHサーバが攻撃を受けていることが分かります。
認証の失敗が繰り返されていることから、おそらくSSHへのブルートフォースアタックです。
ただ、30回程度のアタックでhttpdが落ちることは考えにくいので、不正侵入に成功した可能性が考えられます。意図的にhttpdを落とされた可能性が高いです。他の被害も無いかどうか確認しましょう。
対策としては、以下のような事が考えられます。
ご回答ありがとうございました。
重ねて質問になってしまうのですが，
■ 質問 1
パスワードは, root を含むすべてのユーザが「十分に強度のつよいもの (長さ10文字, 大文字, 小文字, 数字, 記号をランダムにならべたもの)」を使用しているのですが，それでもブルートフォースアタックが成功する (しかも 30回程度の試行で) ことがあるのでしょうか ?
※ パスワードログインができるのはよろしくないので, sshd_config を PasswordAuthentication no に変更はしました。BFA に対する今後の対策としてはこれで十分かと思います。
■ 質問 2
また，BFA が成功していた場合，なにか痕跡が残っていないかと思うのですが，
・/etc/passwd, /etc/shadow あたりは改ざんされていない模様
・/var/log/secure には成功のログは無い (消された ?)
・"chkrootkit -p $SAFE_PLACE" で rootkit は check したが，not infected.
という状態でした。
上記以外になにか
(「xx というツールがインストールされてないかチェックしなさい」 とか 「xx のログをチェックしなさい」 とか)
チェックするポイントがありましたらご教示いただけますと助かります。
No.3
40
もしかすると別の理由でそうゆうことになってしまうようなとこを開いてしまっとかもありえますが、攻撃をするお馬鹿な人たちもいると思います。
役にたたなくてすみません
いろんなひとがいますからね。
お馬鹿なひともいるかもしれませんね。
今回は原因を調べたいので，
「お馬鹿なひとたちはこういう動機 / 思想信条でもって行動していますよ」
というのがわかると助かります。
No.4
966247
ここでベストアンサー
1000pt
Apache Http Server : List of security vulnerabilities
上記ページは、Apache httpd で DoS を引き起こす脆弱性で、確認されているもののリストです。
もし、httpd の停止が、リモートから httpd を直接停止させるようなものであれば、上記リストのいずれかが使われた可能性はあります。ただ、「httpd-2.2.3-65.el5.centos」がリリースされたのは、今年の 6 月で、パッケージの changelog を見ると、今年の 2 月に CVE-2012-0053, CVE-2012-0031, CVE-2011-3607 に対する fix がなされていることから、少なくとも、今年の２月の時点で、クリティカルな問題には対応されている事が期待されます。
もちろん、全ての脆弱性が fix されている訳ではありませんが、逆に、無条件でリモートからサービスを落とせるとは、かなり考えづらいです。
なので、
といった事が考えられます。
sshd へのアクセスを気にされていましたが、sshd へのブルートフォースアタックは日常茶飯事で、そういった記録が /var/log/secure にあること自体は普通です。
ただ、むしろ気になるのは、
下記のようなログが 30回程度繰り返されていました。
たかだか 30 回、というのが気になります。sshd へのブルートフォースアタックは、sshd ポートが開いていると分かると、平気で何時間もアクセスを繰り返します。下手すると半日ぐらい続きます。つまり「30 回」というのが、ブルートフォースに失敗したと考えるには、少なすぎます。もし、sshd へのブルートフォースアタックに成功して、何らかの特権奪取に成功したのであれば、sshd へのログイン成功のログは消去されていると思われますし、httpd を停止する事も可能です。
sshd へのブルートフォースアタックは、手当たり次第に行われていて、踏み台として使うような、「駒」となるホストを得る事が目的な事が多く、httpd の停止は目的ではなく、「駒」にするための作業をしている最中にへまをして止めた、という可能性はあります。
ただ、httpd のバージョンから考えると、きちんとアップデートされているようなので、仮に ssh のブルートフォースアタックに成功しても、特権を取得できるかは疑問です。もし、httpd だけアップデートしているような状況であれば、root の特権を取られる可能性は否定できません。
とりあえず、与えられた情報から推測出来るのは、こんなところです。ssh のブルートフォースアタックが成功した可能性は否定できませんが、きちんとアップデートされていて、おかしな設定をしていなければ、httpd の停止に至るには、ちょっと難しいです。
余談になりますが、可能であれば、ssh を公開鍵認証のみにする事をおすすめします。こうすれば、パスワード認証によるブルートフォースアタックが成功する事はなくなります。
secure ログを拝見させてもらいましたが、3～4秒間隔でトライしているようなので、機械的なブルートフォースアタックかもしれません。手元だと、１秒に１回ぐらいのアタックなので、ずいぶん、のんびりした印象がありますが...
httpd の監視ですが、定期的にプロセスの死活チェックをして、止まっていたらメールを送るような仕掛けをしておくと良いでしょう。Zabbix のような監視ツールを使うのも良いかと思います。そうしておけば、httpd が停止した時間を絞れて、関連するログを時間軸で検証しやすくなります。
ありがとうございます，
httpd の監視は，自前の監視スクリプト + cron でやっていて，
これの設定条件 (実行間隔，リトライの設定等) を見直そうと思います。
Zabbix というのも，使ったことがないのですが，機会があれば使用を検討します。
いろいろとありがとうございました，
ベストアンサーとして質問を終了しましたので。
よろしくお願いします。
No.5
50125
100pt
とりあえずsshdとhttpdのip制限をやったらどうでしょう。
単なる踏み台探しなら、なんらかの対策がとられた時点で、それ以上はやって
こないと思いますが。
http://kazmax.zpp.jp/linux/lin_pam.html
http://www.atmarkit.co.jp/flinux/rensai/apache09/apache09b.html
ご回答ありがとうございます。
とりあえず対策として sshd_config を PasswordAuthentication no に変更はしました。
対策としてはとりあえず上記でよいと思いますが，
できれば 「なぜ httpd が落ちたのか」 を知りたい (できれば物証を得たい) ところです。
No.7
153
100pt
時間的に近接してるところが気になるものの、サーバを公開しているとおかしな攻撃ログはたまにあるものなので、別の方が記されているように30回程度のログであればちょっとチャレンジして諦めた可能性が高いような気がします。
どちらかというと、見た感じ問題がないようであったとしても以下のあたりがどうなっているのか気になります。
パッと見問題なさそうなところも見直すのと、障害発生時点だけでなく障害発生前の起動時点も見てみるとよいのかなと。
/var/log/httpd/access_log
/var/log/httpd/error_log
それと、PHPのエラーログをどこかに吐いているのであればそれもご確認頂くとよいかもしれません（php.iniのerror_logあたりとか。syslogに設定してるのであればsyslog側も）。
また、何となくあまり情報がない気もしますが、一応sarコマンドで対象時期周辺の負荷がどうであったのかも確認はしてみた方がよいかなと。
CentOSであれば/var/log/saに過去分が数世代あると思いますので、
sar -f /var/log/sa/【対象ファイル】
あたりにオプション-uとか-rとか付けてズラーッと出してみて何か特徴的なものが出てないかみてみるとか。
あと、事業者にもよりますが運用的な要因として、サーバメンテだったりメモリ低下だったりで勝手にプロセス殺してしまうこともありますので、借り物のサーバの場合はメンテ情報や（時刻がわからないかもしれませんが）history、およびlast、lastlogなどでコマンドやログイン日時なども確認してみた方がよいかと思います。
場合によってはシレっとリブートされててhttpdサービスが自動起動になってなかったとかあるかもしれません。
なるほど。ご確認ありがとうございます。
> VPS なので，知らない間にログインされる，ということは無いと思います。
ですよね。そのはずですよね。
でもそのはずなのに、そこそこ大手のVPSが2010年末にシレっとミドルウェアをインストールしていたことがありました。
また、既にご存じかもしれませんが、そういったイレギュラーな運用以外に、OpenVZでVPSを実現しているサービスの場合はメモリ状況によって勝手にプロセスを殺すことがありますので、VPS選定時などにご留意頂けるとよいかなと思います（スペック表で保証メモリと最大メモリを分けて書いている場合はOpenVZを使ってるかもしれません）。
追加の情報ありがとうございます，
> そこそこ大手のVPSが2010年末にシレっとミドルウェアをインストールしていたことがありました。
そういうこともあるんですね。
ミドルウェアインストールの影響でプロセスが落ちる，というのはなくは無い気がしますので， (今回は違うようですが) 今後気を付けてみます。
当 VPS は OpenVZ みたいですので，メモリ状況によりプロセスが殺された，というのはありそうな感じがします。
最近の安価な VPS で，年に 2回や 3回ホストやサービス (プロセス) が落ちるのはしょうがないかな，と覚悟はしていますので，No.4 の回答にもありますが，監視を強化する方向で運用しようと思います。あまりにひどいようでしたらもう少し 「高級な」 サーバに引っ越そうと思います。
4
4
2
2
1
secure ログを拝見させてもらいましたが、3～4秒間隔でトライしているようなので、機械的なブルートフォースアタックかもしれません。手元だと、１秒に１回ぐらいのアタックなので、ずいぶん、のんびりした印象がありますが...
2012/09/18 23:28:28httpd の監視ですが、定期的にプロセスの死活チェックをして、止まっていたらメールを送るような仕掛けをしておくと良いでしょう。Zabbix のような監視ツールを使うのも良いかと思います。そうしておけば、httpd が停止した時間を絞れて、関連するログを時間軸で検証しやすくなります。
ありがとうございます，
2012/09/19 00:23:17httpd の監視は，自前の監視スクリプト + cron でやっていて，
これの設定条件 (実行間隔，リトライの設定等) を見直そうと思います。
Zabbix というのも，使ったことがないのですが，機会があれば使用を検討します。
いろいろとありがとうございました，
ベストアンサーとして質問を終了しましたので。
よろしくお願いします。