人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

web サーバが攻撃を受けて httpd プロセスが落ちてしまいました。

わたしが運用している web サーバが攻撃を受けて httpd プロセスが落ちてしまった可能
性がありまして,詳しいことを教えてくださる方,よろしくお願いします。

文字数制限により,状況の詳細に関しては別途投稿します。

知りたいことは以下です。

・「ココを見なさい」 というアドバイス
・攻撃の手法
・攻撃が httpd に具体的にどのような影響を与えたため, httpd が落ちたのか
例:
- 攻撃により CPU/メモリリソースを圧迫したため, httpd が落ちた
- /var/log/secure に残っている攻撃 (sshd に対する攻撃) とは別に,
httpd の脆弱性に対して攻撃を受けたため, httpd が落ちた
・対策
・あるいは, httpd が落ちたほかの原因の可能性

●質問者: h1r0ok
●カテゴリ:コンピュータ
○ 状態 :終了
└ 回答数 : 7/7件

▽最新の回答へ

質問者から

状況の詳細です。

・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 のようです。晒します。


1 ● きゃづみぃ
●0ポイント

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攻撃対策

・十分な帯域をもつネットワークを使用する。
・サーバやネットワーク機器の処理能力を増強する。


h1r0okさんのコメント
ご回答ありがとうございました。 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アドレスを順にチェックしていきます。 それで 攻撃できそうなところみたいだから練習として攻撃されたかもしれません。 ま対策しか書かなかったですけど たいして 何もできないですね。 本格的に攻撃されたら どこも 持ちません。

2 ● oil999
●100ポイント

エラーログから、Webが攻撃を受けたのではなく、SSHサーバが攻撃を受けていることが分かります。
認証の失敗が繰り返されていることから、おそらくSSHへのブルートフォースアタックです。
ただ、30回程度のアタックでhttpdが落ちることは考えにくいので、不正侵入に成功した可能性が考えられます。意図的にhttpdを落とされた可能性が高いです。他の被害も無いかどうか確認しましょう。

対策としては、以下のような事が考えられます。

  1. SSHを使わない
  2. iptablesを使って防ぐ http://blog.browncat.org/2007/07/sshiptables2.html
  3. sshd_config を変更する http://logic.moo.jp/data/archives/644.html

h1r0okさんのコメント
ご回答ありがとうございました。 重ねて質問になってしまうのですが, ■ 質問 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 のログをチェックしなさい」 とか) チェックするポイントがありましたらご教示いただけますと助かります。

3 ● くみ*
●0ポイント

もしかすると別の理由でそうゆうことになってしまうようなとこを開いてしまっとかもありえますが、攻撃をするお馬鹿な人たちもいると思います。

役にたたなくてすみません


h1r0okさんのコメント
いろんなひとがいますからね。 お馬鹿なひともいるかもしれませんね。 今回は原因を調べたいので, 「お馬鹿なひとたちはこういう動機 / 思想信条でもって行動していますよ」 というのがわかると助かります。

4 ● JULY
●1000ポイント ベストアンサー

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 がなされていることから、少なくとも、今年の2月の時点で、クリティカルな問題には対応されている事が期待されます。

もちろん、全ての脆弱性が fix されている訳ではありませんが、逆に、無条件でリモートからサービスを落とせるとは、かなり考えづらいです。

なので、

といった事が考えられます。

sshd へのアクセスを気にされていましたが、sshd へのブルートフォースアタックは日常茶飯事で、そういった記録が /var/log/secure にあること自体は普通です。

ただ、むしろ気になるのは、

下記のようなログが 30回程度繰り返されていました。

たかだか 30 回、というのが気になります。sshd へのブルートフォースアタックは、sshd ポートが開いていると分かると、平気で何時間もアクセスを繰り返します。下手すると半日ぐらい続きます。つまり「30 回」というのが、ブルートフォースに失敗したと考えるには、少なすぎます。もし、sshd へのブルートフォースアタックに成功して、何らかの特権奪取に成功したのであれば、sshd へのログイン成功のログは消去されていると思われますし、httpd を停止する事も可能です。

sshd へのブルートフォースアタックは、手当たり次第に行われていて、踏み台として使うような、「駒」となるホストを得る事が目的な事が多く、httpd の停止は目的ではなく、「駒」にするための作業をしている最中にへまをして止めた、という可能性はあります。

ただ、httpd のバージョンから考えると、きちんとアップデートされているようなので、仮に ssh のブルートフォースアタックに成功しても、特権を取得できるかは疑問です。もし、httpd だけアップデートしているような状況であれば、root の特権を取られる可能性は否定できません。

とりあえず、与えられた情報から推測出来るのは、こんなところです。ssh のブルートフォースアタックが成功した可能性は否定できませんが、きちんとアップデートされていて、おかしな設定をしていなければ、httpd の停止に至るには、ちょっと難しいです。

余談になりますが、可能であれば、ssh を公開鍵認証のみにする事をおすすめします。こうすれば、パスワード認証によるブルートフォースアタックが成功する事はなくなります。


h1r0okさんのコメント
大変詳しい説明,また,すばらしい洞察です,ありがとうございました。ためになります。 結局 「ブルートフォースアタックが成功したのか否か」 が気になるところで,上の No.2 のご回答への質問と同じになってしまうのですが, ■ 質問 1 パスワードは, root を含むすべてのユーザが「十分に強度のつよいもの (長さ10文字, 大文字, 小文字, 数字, 記号をランダムにならべたもの)」を使用しているのですが,それでも BFA が成功する (しかも 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 のログをチェックしなさい」 とか) チェックするポイントがありましたらご教示いただけますと助かります。

JULYさんのコメント
10 文字以上、ランダムで文字種に偏りのないパスワードで、ブルートフォースアタックを突破される可能性は、極めて低いです。ただ、例えば、キー配列を使ったような物は、見た目はランダムでも、規則性をもって作られたものなので、攻撃用の辞書に載っている可能性は高いです。パスワードの設定に気を遣われているようなので、あとは、ログインが無効になっているはずのシステムアカウントが有効になっていた、という事が無ければ、ブルートフォースアタックで破られた可能性は、充分に低いはずです。 ただ、たかだか 30 回のブルートフォースは、気にはなります。掲載されている2回分のログだけでは分かりませんが、1回目と2回目の間が 14 秒と離れている事を考えると、機械的なブルートフォースアタックではなく、手入力の可能性も否定できません。だとすれば、30 回であきらめる事も考えられます。まぁ、今時、手入力で ssh での認証を試す、というのも、ちょっとどうかなぁ、とも思いますが。 個人的な感想としては、httpd が落ちたのは、例えば、再現性の低いメモリやディスク周りでの障害で「たまたま」で、少なくとも、スクリプト・キディによる簡単な侵入を許した、という状況ではないと思います。逆に、侵入を許したとすれば、既存のチェックツールやログを調べるといった程度では痕跡が見つからないレベルになっていると思います。 私も、フォレンジック・ツールを使いこなすような知識は持ち合わせていないので、これが限界です。サーバとインターネットの間の通信をパケットキャプチャ等で、不審な通信が無いかを観測すると、ひょっとしたら何か見つかるかもしれませんが、不安であれば、OS から再インストールする事をおすすめします。

h1r0okさんのコメント
ご回答ありがとうございます。 上に張り付けた /var/log/secure は,文字数の都合で適当に切り貼りしてあります。 該当部分 (9/16 10時ごろ) をアップロードしましたので,よかったら見てみてください。 http://yahoo.jp/VMo3gu なにか新しいことがわかりましたら是非ご教示お願いします。 で,もろもろまとめますと, ・httpd は「たまたま」落ちたらしい ・たぶん BFA による侵入はされてない ・BFA と httpd はたぶん無関係 といった感じのようですね。わたしもそうではないかなと思います。 「侵入されなかったことを証明」するのは「侵入されたことを証明」するよりも難しいでしょうから,証明はできないですが。 対策としては,下記のようにしようと思います。 ・BFA 対策にパスワードログインを禁止する ・httpd がまた「たまたま」落ちるかもしれないので,監視を頻繁に行う -> あまりに頻繁に落ちるようであれば困るので,別途対策を考える いじょう,ありがとうございました。

JULYさんのコメント
secure ログを拝見させてもらいましたが、3?4秒間隔でトライしているようなので、機械的なブルートフォースアタックかもしれません。手元だと、1秒に1回ぐらいのアタックなので、ずいぶん、のんびりした印象がありますが... httpd の監視ですが、定期的にプロセスの死活チェックをして、止まっていたらメールを送るような仕掛けをしておくと良いでしょう。Zabbix のような監視ツールを使うのも良いかと思います。そうしておけば、httpd が停止した時間を絞れて、関連するログを時間軸で検証しやすくなります。

h1r0okさんのコメント
ありがとうございます, httpd の監視は,自前の監視スクリプト + cron でやっていて, これの設定条件 (実行間隔,リトライの設定等) を見直そうと思います。 Zabbix というのも,使ったことがないのですが,機会があれば使用を検討します。 いろいろとありがとうございました, ベストアンサーとして質問を終了しましたので。 よろしくお願いします。

1-5件表示/8件
4.前の5件|次5件6.
関連質問

●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ